一、簡單
俗話說，沒有比較就沒有傷害。這裏咱們還是通過對比來介紹LockSupport的簡單。
在沒有LockSupport之前，線程的掛起和喚醒咱們都是通過Object的wait和notify/notifyAll方法實現。
寫一段例子代碼，線程A執行一段業務邏輯後調用wait阻塞住自己。主線程調用notify方法喚醒線程A，線程A然後打印自己執行的結果。
public class TestObjWait {
public static void main(String[] args)throws Exception {
final Object obj = new Object();
Thread A = new Thread(new Runnable() {
@Override
public void run() {
int sum = 0;
for(int i=0;i<10;i++){
sum+=i;
}
try {
obj.wait();
}catch (Exception e){
e.printStackTrace();
}
System.out.println(sum);
}
});
A.start();
//睡眠一秒鐘，保證線程A已經計算完成，阻塞在wait方法
Thread.sleep(1000);
obj.notify();
}
}
執行這段代碼，不難發現這個錯誤：
Exception in thread "main" java.lang.IllegalMonitorStateException
at java.lang.Object.notify(Native Method)
原因很簡單，wait和notify/notifyAll方法只能在同步代碼塊裏用(這個有的面試官也會考察)。所以將代碼修改爲如下就可正常運行了：
public class TestObjWait {
public static void main(String[] args)throws Exception {
final Object obj = new Object();
Thread A = new Thread(new Runnable() {
@Override
public void run() {
int sum = 0;
for(int i=0;i<10;i++){
sum+=i;
}
try {
synchronized (obj){
obj.wait();
}
}catch (Exception e){
e.printStackTrace();
}
System.out.println(sum);
}
});
A.start();
//睡眠一秒鐘，保證線程A已經計算完成，阻塞在wait方法
Thread.sleep(1000);
synchronized (obj){
obj.notify();
}
}
}
那如果咱們換成LockSupport呢？簡單得很，看代碼：
public class TestObjWait {
public static void main(String[] args)throws Exception {
Thread A = new Thread(new Runnable() {
@Override
public void run() {
int sum = 0;
for(int i=0;i<10;i++){
sum+=i;
}
LockSupport.park();
System.out.println(sum);
}
});
A.start();
//睡眠一秒鐘，保證線程A已經計算完成，阻塞在wait方法
Thread.sleep(1000);
LockSupport.unpark(A);
}
}
直接調用就可以了，沒有說非得在同步代碼塊裏才能用。簡單吧。
二、靈活
如果只是LockSupport在使用起來比Object的wait/notify簡單，那還真沒必要專門講解下LockSupport。最主要的是靈活性。
上邊的例子代碼中，主線程調用了Thread.sleep(1000)方法來等待線程A計算完成進入wait狀態。如果去掉Thread.sleep()調用，代碼如下：
public class TestObjWait {
public static void main(String[] args)throws Exception {
final Object obj = new Object();
Thread A = new Thread(new Runnable() {
@Override
public void run() {
int sum = 0;
for(int i=0;i<10;i++){
sum+=i;
}
try {
synchronized (obj){
obj.wait();
}
}catch (Exception e){
e.printStackTrace();
}
System.out.println(sum);
}
});
A.start();
//睡眠一秒鐘，保證線程A已經計算完成，阻塞在wait方法
//Thread.sleep(1000);
synchronized (obj){
obj.notify();
}
}
}
多運行幾次上邊的代碼，有的時候能夠正常打印結果並退出程序，但有的時候線程無法打印結果阻塞住了。原因就在於：主線程調用完notify後，線程A才進入wait方法，導致線程A一直阻塞住。由於線程A不是後臺線程，所以整個程序無法退出。
那如果換做LockSupport呢？LockSupport就支持主線程先調用unpark後，線程A再調用park而不被阻塞嗎？是的，沒錯。代碼如下：
public class TestObjWait {
public static void main(String[] args)throws Exception {
final Object obj = new Object();
Thread A = new Thread(new Runnable() {
@Override
public void run() {
int sum = 0;
for(int i=0;i<10;i++){
sum+=i;
}
LockSupport.park();
System.out.println(sum);
}
});
A.start();
//睡眠一秒鐘，保證線程A已經計算完成，阻塞在wait方法
//Thread.sleep(1000);
LockSupport.unpark(A);
}
}
不管你執行多少次，這段代碼都能正常打印結果並退出。這就是LockSupport最大的靈活所在。
總結一下，LockSupport比Object的wait/notify有兩大優勢：
①LockSupport不需要在同步代碼塊裏 。所以線程間也不需要維護一個共享的同步對象了，實現了線程間的解耦。
②unpark函數可以先於park調用，所以不需要擔心線程間的執行的先後順序。
三、應用廣泛
LockSupport在Java的工具類用應用很廣泛，咱們這裏找幾個例子感受感受。以Java裏最常用的類ThreadPoolExecutor爲例。先看如下代碼：
public class TestObjWait {
public static void main(String[] args)throws Exception {
ArrayBlockingQueue<Runnable> queue = new ArrayBlockingQueue<Runnable>(1000);
ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(5,5,1000, TimeUnit.SECONDS,queue);
Future<String> future = poolExecutor.submit(new Callable<String>() {
@Override
public String call() throws Exception {
TimeUnit.SECONDS.sleep(5);
return "hello";
}
});
String result = future.get();
System.out.println(result);
}
}
代碼中我們向線程池中扔了一個任務，然後調用Future的get方法，同步阻塞等待線程池的執行結果。
這裏就要問了：get方法是如何組塞住當前線程？線程池執行完任務後又是如何喚醒線程的呢？
咱們跟着源碼一步步分析，先看線程池的submit方法的實現：
在submit方法裏，線程池將我們提交的基於Callable實現的任務，封裝爲基於RunnableFuture實現的任務，然後將任務提交到線程池執行，並向當前線程返回RunnableFutrue。
進入newTaskFor方法，就一句話：return new FutureTask<T>(callable);
所以，咱們主線程調用future的get方法就是FutureTask的get方法，線程池執行的任務對象也是FutureTask的實例。
接下來看看FutureTask的get方法的實現：
比較簡單，就是判斷下當前任務是否執行完畢，如果執行完畢直接返回任務結果，否則進入awaitDone方法阻塞等待。
awaitDone方法裏，首先會用到上節講到的cas操作，將線程封裝爲WaitNode，保持下來，以供後續喚醒線程時用。再就是調用了LockSupport的park/parkNanos組塞住當前線程。
上邊已經說完了阻塞等待任務結果的邏輯，接下來再看看線程池執行完任務，喚醒等待線程的邏輯實現。
前邊說了，咱們提交的基於Callable實現的任務，已經被封裝爲FutureTask任務提交給了線程池執行，任務的執行就是FutureTask的run方法執行。如下是FutureTask的run方法：
c.call()就是執行我們提交的任務，任務執行完後調用了set方法，進入set方法發現set方法調用了finishCompletion方法，想必喚醒線程的工作就在這裏邊了，看看代碼實現吧：
沒錯就在這裏邊，先是通過cas操作將所有等待的線程拿出來，然後便使用LockSupport的unpark喚醒每個線程。
在使用線程池的過程中，不知道你有沒有這麼一個疑問：線程池裏沒有任務時，線程池裏的線程在幹嘛呢？
看過我的這篇文章《線程池的工作原理與源碼解讀》的讀者一定知道，線程會調用隊列的take方法阻塞等待新任務。那隊列的take方法是不是也跟Future的get方法實現一樣呢？咱們來看看源碼實現。
以ArrayBlockingQueue爲例，take方法實現如下：
與想象的有點出入，他是使用了Lock的Condition的await方法實現線程阻塞。但當我們繼續追下去進入await方法，發現還是使用了LockSupport：
限於篇幅，jdk裏的更多應用就不再追下去了。
四、LockSupport的實現
學習要知其然，還要知其所以然。接下來不妨看看LockSupport的實現。
進入LockSupport的park方法，可以發現它是調用了Unsafe的park方法，這是一個本地native方法，只能通過openjdk的源碼看看其本地實現了。
它調用了線程的Parker類型對象的park方法，如下是Parker類的定義：
類中定義了一個int類型的_counter變量，咱們上文中講靈活性的那一節說，可以先執行unpark後執行park，就是通過這個變量實現，看park方法的實現代碼(由於方法比較長就不整體截圖了)：
park方法會調用Atomic::xchg方法，這個方法會原子性的將_counter賦值爲0，並返回賦值前的值。如果調用park方法前，_counter大於0，則說明之前調用過unpark方法，所以park方法直接返回。
接着往下看：
實際上Parker類用Posix的mutex，condition來實現的阻塞喚醒。如果對mutex和condition不熟，可以簡單理解爲mutex就是Java裏的synchronized，condition就是Object裏的wait/notify操作。
park方法裏調用pthread_mutex_trylock方法，就相當於Java線程進入Java的同步代碼塊，然後再次判斷_counter是否大於零，如果大於零則將_counter設置爲零。最後調用pthread_mutex_unlock解鎖，相當於Java執行完退出同步代碼塊。如果_counter不大於零，則繼續往下執行pthread_cond_wait方法，實現當前線程的阻塞。
最後再看看unpark方法的實現吧，這塊就簡單多了，直接上代碼：
圖中的1和4就相當於Java的進入synchronized和退出synchronized的加鎖解鎖操作，代碼2將_counter設置爲1，同時判斷先前_counter的值是否小於1，即這段代碼：if(s<1)。如果不小於1，則就不會有線程被park，所以方法直接執行完畢，否則就會執行代碼3，來喚醒被阻塞的線程。
通過閱讀LockSupport的本地實現，我們不難發現這麼個問題：多次調用unpark方法和調用一次unpark方法效果一樣，因爲都是直接將_counter賦值爲1，而不是加1。簡單說就是：線程A連續調用兩次LockSupport.unpark(B)方法喚醒線程B，然後線程B調用兩次LockSupport.park()方法， 線程B依舊會被阻塞。因爲兩次unpark調用效果跟一次調用一樣，只能讓線程B的第一次調用park方法不被阻塞，第二次調用依舊會阻塞。
