摘要：此對(duì)象在線程受阻塞時(shí)被記錄，以允許監(jiān)視工具和診斷工具確定線程受阻塞的原因。阻塞當(dāng)前線程，最長不超過納秒，返回條件在的基礎(chǔ)上增加了超時(shí)返回。喚醒線程喚醒處于阻塞狀態(tài)的線程。

LockSupport 和 CAS 是Java并發(fā)包中很多并發(fā)工具控制機(jī)制的基礎(chǔ)，它們底層其實(shí)都是依賴Unsafe實(shí)現(xiàn)。

LockSupport是用來創(chuàng)建鎖和其他同步類的基本線程阻塞原語。LockSupport 提供park()和unpark()方法實(shí)現(xiàn)阻塞線程和解除線程阻塞，LockSupport和每個(gè)使用它的線程都與一個(gè)許可(permit)關(guān)聯(lián)。permit相當(dāng)于1，0的開關(guān)，默認(rèn)是0，調(diào)用一次unpark就加1變成1，調(diào)用一次park會(huì)消費(fèi)permit, 也就是將1變成0，同時(shí)park立即返回。再次調(diào)用park會(huì)變成block（因?yàn)閜ermit為0了，會(huì)阻塞在這里，直到permit變?yōu)?）, 這時(shí)調(diào)用unpark會(huì)把permit置為1。每個(gè)線程都有一個(gè)相關(guān)的permit, permit最多只有一個(gè)，重復(fù)調(diào)用unpark也不會(huì)積累。

park()和unpark()不會(huì)有 “Thread.suspend和Thread.resume所可能引發(fā)的死鎖” 問題，由于許可的存在，調(diào)用 park 的線程和另一個(gè)試圖將其 unpark 的線程之間的競爭將保持活性。

如果調(diào)用線程被中斷，則park方法會(huì)返回。同時(shí)park也擁有可以設(shè)置超時(shí)時(shí)間的版本。

需要特別注意的一點(diǎn)：park 方法還可以在其他任何時(shí)間“毫無理由”地返回，因此通常必須在重新檢查返回條件的循環(huán)里調(diào)用此方法。從這個(gè)意義上說，park 是“忙碌等待”的一種優(yōu)化，它不會(huì)浪費(fèi)這么多的時(shí)間進(jìn)行自旋，但是必須將它與 unpark 配對(duì)使用才更高效。

三種形式的 park 還各自支持一個(gè) blocker 對(duì)象參數(shù)。此對(duì)象在線程受阻塞時(shí)被記錄，以允許監(jiān)視工具和診斷工具確定線程受阻塞的原因。（這樣的工具可以使用方法 getBlocker(java.lang.Thread) 訪問 blocker。）建議最好使用這些形式，而不是不帶此參數(shù)的原始形式。在鎖實(shí)現(xiàn)中提供的作為 blocker 的普通參數(shù)是 this。
看下線程dump的結(jié)果來理解blocker的作用。

從線程dump結(jié)果可以看出：
有blocker的可以傳遞給開發(fā)人員更多的現(xiàn)場信息，可以查看到當(dāng)前線程的阻塞對(duì)象，方便定位問題。所以java6新增加帶blocker入?yún)⒌南盗衟ark方法，替代原有的park方法。

看一個(gè)Java docs中的示例用法：一個(gè)先進(jìn)先出非重入鎖類的框架

class FIFOMutex {
    private final AtomicBoolean locked = new AtomicBoolean(false);
    private final Queue waiters
      = new ConcurrentLinkedQueue();
 
    public void lock() {
      boolean wasInterrupted = false;
      Thread current = Thread.currentThread();
      waiters.add(current);
 
      // Block while not first in queue or cannot acquire lock
      while (waiters.peek() != current ||
             !locked.compareAndSet(false, true)) {
        LockSupport.park(this);
        if (Thread.interrupted()) // ignore interrupts while waiting
          wasInterrupted = true;
      }

      waiters.remove();
      if (wasInterrupted)          // reassert interrupt status on exit
        current.interrupt();
    }
 
    public void unlock() {
      locked.set(false);
      LockSupport.unpark(waiters.peek());
    }
  }}

LockSupport中主要的兩個(gè)成員變量：

// Hotspot implementation via intrinsics API
    private static final sun.misc.Unsafe UNSAFE;
    private static final long parkBlockerOffset;

unsafe:全名sun.misc.Unsafe可以直接操控內(nèi)存，被JDK廣泛用于自己的包中，如java.nio和java.util.concurrent。但是不建議在生產(chǎn)環(huán)境中使用這個(gè)類。因?yàn)檫@個(gè)API十分不安全、不輕便、而且不穩(wěn)定。
LockSupport的方法底層都是調(diào)用Unsafe的方法實(shí)現(xiàn)。

再來看parkBlockerOffset:
parkBlocker就是第一部分說到的用于記錄線程被誰阻塞的，用于線程監(jiān)控和分析工具來定位原因的，可以通過LockSupport的getBlocker獲取到阻塞的對(duì)象。

 static {
        try {
            UNSAFE = sun.misc.Unsafe.getUnsafe();
            Class tk = Thread.class;
            parkBlockerOffset = UNSAFE.objectFieldOffset
                (tk.getDeclaredField("parkBlocker"));
        } catch (Exception ex) { throw new Error(ex); }
 }

從這個(gè)靜態(tài)語句塊可以看的出來，先是通過反射機(jī)制獲取Thread類的parkBlocker字段對(duì)象。然后通過sun.misc.Unsafe對(duì)象的objectFieldOffset方法獲取到parkBlocker在內(nèi)存里的偏移量，parkBlockerOffset的值就是這么來的.

JVM的實(shí)現(xiàn)可以自由選擇如何實(shí)現(xiàn)Java對(duì)象的“布局”，也就是在內(nèi)存里Java對(duì)象的各個(gè)部分放在哪里，包括對(duì)象的實(shí)例字段和一些元數(shù)據(jù)之類。 sun.misc.Unsafe里關(guān)于對(duì)象字段訪問的方法把對(duì)象布局抽象出來，它提供了objectFieldOffset()方法用于獲取某個(gè)字段相對(duì) Java對(duì)象的“起始地址”的偏移量，也提供了getInt、getLong、getObject之類的方法可以使用前面獲取的偏移量來訪問某個(gè)Java 對(duì)象的某個(gè)字段。

為什么要用偏移量來獲取對(duì)象？干嗎不要直接寫個(gè)get，set方法。多簡單？
仔細(xì)想想就能明白，這個(gè)parkBlocker就是在線程處于阻塞的情況下才會(huì)被賦值。線程都已經(jīng)阻塞了，如果不通過這種內(nèi)存的方法，而是直接調(diào)用線程內(nèi)的方法，線程是不會(huì)回應(yīng)調(diào)用的。

2.LockSupport的方法：

可以看到，LockSupport中主要是park和unpark方法以及設(shè)置和讀取parkBlocker方法。

 private static void setBlocker(Thread t, Object arg) {
        // Even though volatile, hotspot doesn"t need a write barrier here.
        UNSAFE.putObject(t, parkBlockerOffset, arg);
  }

對(duì)給定線程t的parkBlocker賦值。

    public static Object getBlocker(Thread t) {
        if (t == null)
            throw new NullPointerException();
        return UNSAFE.getObjectVolatile(t, parkBlockerOffset);
    }
  

從線程t中獲取它的parkBlocker對(duì)象，即返回的是阻塞線程t的Blocker對(duì)象。

接下來主查兩類方法，一類是阻塞park方法，一類是解除阻塞unpark方法

阻塞線程

park()

public static void park() {
        UNSAFE.park(false, 0L);
}

調(diào)用native方法阻塞當(dāng)前線程。

parkNanos(long nanos)

public static void parkNanos(long nanos) {
        if (nanos > 0)
            UNSAFE.park(false, nanos);
}

阻塞當(dāng)前線程，最長不超過nanos納秒，返回條件在park()的基礎(chǔ)上增加了超時(shí)返回。

parkUntil(long deadline)

public static void parkUntil(long deadline) {
  UNSAFE.park(true, deadline);
}

阻塞當(dāng)前線程，知道deadline時(shí)間（deadline - 毫秒數(shù)）。

JDK1.6引入這三個(gè)方法對(duì)應(yīng)的擁有Blocker版本。

park(Object blocker)

public static void park(Object blocker) {
  Thread t = Thread.currentThread();
  setBlocker(t, blocker);
  UNSAFE.park(false, 0L);
  setBlocker(t, null);
}

1) 記錄當(dāng)前線程等待的對(duì)象（阻塞對(duì)象）；
2) 阻塞當(dāng)前線程；
3) 當(dāng)前線程等待對(duì)象置為null。

parkNanos(Object blocker, long nanos)

public static void parkNanos(Object blocker, long nanos) {
  if (nanos > 0) {
      Thread t = Thread.currentThread();
      setBlocker(t, blocker);
      UNSAFE.park(false, nanos);
      setBlocker(t, null);
  }
}

阻塞當(dāng)前線程，最長等待時(shí)間不超過nanos毫秒，同樣，在阻塞當(dāng)前線程的時(shí)候做了記錄當(dāng)前線程等待的對(duì)象操作。

parkUntil(Object blocker, long deadline)

public static void parkUntil(Object blocker, long deadline) {
  Thread t = Thread.currentThread();
  setBlocker(t, blocker);
  UNSAFE.park(true, deadline);
  setBlocker(t, null);
}

阻塞當(dāng)前線程直到deadline時(shí)間，相同的，也做了阻塞前記錄當(dāng)前線程等待對(duì)象的操作。

喚醒線程

unpark(Thread thread)

public static void unpark(Thread thread) {
  if (thread != null)
      UNSAFE.unpark(thread);
}

喚醒處于阻塞狀態(tài)的線程Thread。

參考：
http://tool.oschina.net/apido...
http://ifeve.com/locksuppor-s...
http://www.jianshu.com/p/ceb8...
http://15838341661-139-com.it...