看jstack輸出的時候，可以發(fā)現(xiàn)很多狀態(tài)都是TIMED_WAITING(parking)，如下所示：

"http-bio-8080-exec-16" #70 daemon prio=5 os_prio=0 tid=0x00007f6088027800 nid=0x3a1f waiting on condition [0x00007f60fcd03000]

java.lang.Thread.State: TIMED_WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

- parking to wait for <0x00000006cb8d7500> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)

at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)

at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)

at java.util.concurrent.LinkedBlockingQueue.poll(LinkedBlockingQueue.java:467)

at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:86)

at org.apache.tomcat.util.threads.TaskQueue.poll(TaskQueue.java:32)

at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1066)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Thread.java:745)

關(guān)于LockSupport，查看相關(guān)資料，可知LockSupport類是Java6(JSR166-JUC)引入的一個類，提供了基本的線程同步原語。LockSupport實際上是調(diào)用了Unsafe類里的函數(shù)，歸結(jié)到Unsafe里，只有兩個函數(shù)：

public?native?void?unpark(Thread?jthread);

public?native?void?park(boolean?isAbsolute,?long?time);

isAbsolute參數(shù)是指明時間是絕對的，還是相對的。

僅僅兩個簡單的接口，就為上層提供了強大的同步原語。

先來解析下兩個函數(shù)是做什么的。

unpark函數(shù)為線程提供“許可(permit)”，線程調(diào)用park函數(shù)則等待“許可”。這個有點像信號量，但是這個“許可”是不能疊加的，“許可”是一次性的。

比如線程B連續(xù)調(diào)用了三次unpark函數(shù)，當(dāng)線程A調(diào)用park函數(shù)就使用掉這個“許可”，如果線程A再次調(diào)用park，則進(jìn)入等待狀態(tài)。

注意，unpark函數(shù)可以先于park調(diào)用。比如線程B調(diào)用unpark函數(shù)，給線程A發(fā)了一個“許可”，那么當(dāng)線程A調(diào)用park時，它發(fā)現(xiàn)已經(jīng)有“許可”了，那么它會馬上再繼續(xù)運行。

在JDK 5里面，是用wait/notify/notifyAll來同步的，它沒有LockSupport那樣的容忍性，所以JDK7 JUC之后幾乎都是采用park與unpark實現(xiàn)。?至于其提供的額外監(jiān)視器參數(shù)，主要是jstack排查方便。

我們知道，線程的shutdown從標(biāo)準(zhǔn)的角度來說，就是給線程發(fā)送一個interupt，線程自行決定是否響應(yīng)，具體是否相應(yīng)的標(biāo)準(zhǔn)如下：

interrupt

public?void?interrupt()

Interrupts this thread.

Unless the current thread is interrupting itself, which is always permitted, the?checkAccess?method of this thread is invoked, which may cause a?SecurityException?to be thrown.

If this thread is blocked in an invocation of the?wait(),?wait(long), or?wait(long, int)?methods of the?Object?class, or of the?join(),?join(long),?join(long, int),?sleep(long), or?sleep(long, int), methods of this class, then its interrupt status will be cleared and it will receive an?InterruptedException. (這是正確而且必須的行為，否則就有可能會導(dǎo)致共享變量處于不一致的狀態(tài))

If this thread is blocked in an I/O operation upon an?interruptible channel?then the channel will be closed, the thread's interrupt status will be set, and the thread will receive a?ClosedByInterruptException.

If this thread is blocked in a?Selector?then the thread's interrupt status will be set and it will return immediately from the selection operation, possibly with a non-zero value, just as if the selector's?wakeup?method were invoked.

If none of the previous conditions hold then this thread's interrupt status will be set.

Interrupting a thread that is not alive need not have any effect.

Throws:

所以，對于那些無法響應(yīng)中斷的線程中的邏輯，我們需要根據(jù)isInterupted來判斷決定是否終止自己，不過不可否認(rèn)的是，現(xiàn)實中有很多的應(yīng)用并沒有這么做。關(guān)于對中斷的處理方式，可參考Java theory and practice: Dealing with InterruptedException?。

最后看一下，對于那些使用park阻塞的線程，是否支持Interrupt，看javadoc是支持的，如下：

關(guān)于java中斷，講得比較好的帖子是：

http://agapple.iteye.com/blog/970055

關(guān)于LockSupport，可參見：

http://blog.csdn.net/hengyunabc/article/details/28126139

以及java doc參考https://docs.oracle.com/javase/7/docs/api/.

總結(jié)

以上是生活随笔為你收集整理的java中的locksupport_java中线程的停止以及LockSupport工具类的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。