作者：烏梟
來源：https://blog.csdn.net/qq_34039315/article/details/78549311

1、在java中守護線程和本地線程區別？

java中的線程分爲兩種：守護線程（Daemon）和用戶線程（User）。

任何線程都可以設置爲守護線程和用戶線程，通過方法Thread.setDaemon(bool on)；true則把該線程設置爲守護線程，反之則爲用戶線程。Thread.setDaemon()必須在Thread.start()之前調用，否則運行時會拋出異常。

兩者的區別：

唯一的區別是判斷虛擬機(JVM)何時離開，Daemon是爲其他線程提供服務，如果全部的User Thread已經撤離，Daemon 沒有可服務的線程，JVM撤離。也可以理解爲守護線程是JVM自動創建的線程（但不一定），用戶線程是程序創建的線程；比如JVM的垃圾回收線程是一個守護線程，當所有線程已經撤離，不再產生垃圾，守護線程自然就沒事可幹了，當垃圾回收線程是Java虛擬機上僅剩的線程時，Java虛擬機會自動離開。

擴展：Thread Dump打印出來的線程信息，含有daemon字樣的線程即爲守護進程，可能會有：服務守護進程、編譯守護進程、windows下的監聽Ctrl+break的守護進程、Finalizer守護進程、引用處理守護進程、GC守護進程。

2、線程與進程的區別？

進程是操作系統分配資源的最小單元，線程是操作系統調度的最小單元。

一個程序至少有一個進程,一個進程至少有一個線程。

3、什麼是多線程中的上下文切換？

多線程會共同使用一組計算機上的CPU，而線程數大於給程序分配的CPU數量時，爲了讓各個線程都有執行的機會，就需要輪轉使用CPU。不同的線程切換使用CPU發生的切換數據等就是上下文切換。

4、死鎖與活鎖的區別，死鎖與飢餓的區別？

死鎖：是指兩個或兩個以上的進程（或線程）在執行過程中，因爭奪資源而造成的一種互相等待的現象，若無外力作用，它們都將無法推進下去。

產生死鎖的必要條件：

• 互斥條件：所謂互斥就是進程在某一時間內獨佔資源。
• 請求與保持條件：一個進程因請求資源而阻塞時，對已獲得的資源保持不放。
• 不剝奪條件:進程已獲得資源，在末使用完之前，不能強行剝奪。
• 循環等待條件:若干進程之間形成一種頭尾相接的循環等待資源關係。

活鎖：任務或者執行者沒有被阻塞，由於某些條件沒有滿足，導致一直重複嘗試，失敗，嘗試，失敗。

活鎖和死鎖的區別在於，處於活鎖的實體是在不斷的改變狀態，所謂的“活”， 而處於死鎖的實體表現爲等待；活鎖有可能自行解開，死鎖則不能。

飢餓：一個或者多個線程因爲種種原因無法獲得所需要的資源，導致一直無法執行的狀態。

Java中導致飢餓的原因：

• 高優先級線程吞噬所有的低優先級線程的CPU時間。
• 線程被永久堵塞在一個等待進入同步塊的狀態，因爲其他線程總是能在它之前持續地對該同步塊進行訪問。
• 線程在等待一個本身也處於永久等待完成的對象(比如調用這個對象的wait方法)，因爲其他線程總是被持續地獲得喚醒。

5、Java中用到的線程調度算法是什麼？

採用時間片輪轉的方式。可以設置線程的優先級，會映射到下層的系統上面的優先級上，如非特別需要，儘量不要用，防止線程飢餓。

6、什麼是線程組，爲什麼在Java中不推薦使用？

ThreadGroup類，可以把線程歸屬到某一個線程組中，線程組中可以有線程對象，也可以有線程組，組中還可以有線程，這樣的組織結構有點類似於樹的形式。

爲什麼不推薦使用？因爲使用有很多的安全隱患吧，沒有具體追究，如果需要使用，推薦使用線程池。

7、爲什麼使用Executor框架？

1. 每次執行任務創建線程 new Thread()比較消耗性能，創建一個線程是比較耗時、耗資源的。
2. 調用 new Thread()創建的線程缺乏管理，被稱爲野線程，而且可以無限制的創建，線程之間的相互競爭會導致過多佔用系統資源而導致系統癱瘓，還有線程之間的頻繁交替也會消耗很多系統資源。
3. 接使用new Thread() 啓動的線程不利於擴展，比如定時執行、定期執行、定時定期執行、線程中斷等都不便實現。

8、在Java中Executor和Executors的區別？

Executors 工具類的不同方法按照我們的需求創建了不同的線程池，來滿足業務的需求。

Executor 接口對象能執行我們的線程任務。

ExecutorService接口繼承了Executor接口並進行了擴展，提供了更多的方法我們能獲得任務執行的狀態並且可以獲取任務的返回值。

使用ThreadPoolExecutor 可以創建自定義線程池。

Future 表示異步計算的結果，他提供了檢查計算是否完成的方法，以等待計算的完成，並可以使用get()方法獲取計算的結果。

9、什麼是原子操作？在Java Concurrency API中有哪些原子類(atomic classes)？

原子操作（atomic operation）意爲”不可被中斷的一個或一系列操作” 。

處理器使用基於對緩存加鎖或總線加鎖的方式來實現多處理器之間的原子操作。

在Java中可以通過鎖和循環CAS的方式來實現原子操作。 CAS操作——Compare & Set，或是 Compare & Swap，現在幾乎所有的CPU指令都支持CAS的原子操作。

原子操作是指一個不受其他操作影響的操作任務單元。原子操作是在多線程環境下避免數據不一致必須的手段。

int++並不是一個原子操作，所以當一個線程讀取它的值並加1時，另外一個線程有可能會讀到之前的值，這就會引發錯誤。

爲了解決這個問題，必須保證增加操作是原子的，在JDK1.5之前我們可以使用同步技術來做到這一點。到JDK1.5，java.util.concurrent.atomic包提供了int和long類型的原子包裝類，它們可以自動的保證對於他們的操作是原子的並且不需要使用同步。

java.util.concurrent這個包裏面提供了一組原子類。其基本的特性就是在多線程環境下，當有多個線程同時執行這些類的實例包含的方法時，具有排他性，即當某個線程進入方法，執行其中的指令時，不會被其他線程打斷，而別的線程就像自旋鎖一樣，一直等到該方法執行完成，才由JVM從等待隊列中選擇一個另一個線程進入，這只是一種邏輯上的理解。

原子類：AtomicBoolean，AtomicInteger，

AtomicLong，AtomicReference

原子數組：AtomicIntegerArray,

AtomicLongArray，AtomicReferenceArray

原子屬性更新器：

AtomicLongFieldUpdater,

AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater

解決ABA問題的原子類：

AtomicMarkableReference

(通過引入一個boolean來反映中間有沒有變過）AtomicStampedReference

（通過引入一個int來累加來反映中間有沒有變過）

10、Java Concurrency API中的Lock接口(Lock interface)是什麼？對比同步它有什麼優勢？

Lock接口比同步方法和同步塊提供了更具擴展性的鎖操作。

他們允許更靈活的結構，可以具有完全不同的性質，並且可以支持多個相關類的條件對象。

它的優勢有：

• 可以使鎖更公平
• 可以使線程在等待鎖的時候響應中斷
• 可以讓線程嘗試獲取鎖，並在無法獲取鎖的時候立即返回或者等待一段時間
• 可以在不同的範圍，以不同的順序獲取和釋放鎖

整體上來說Lock是synchronized的擴展版，Lock提供了無條件的、可輪詢的(tryLock方法)、定時的(tryLock帶參方法)、可中斷的(lockInterruptibly)、可多條件隊列的(newCondition方法)鎖操作。另外Lock的實現類基本都支持非公平鎖(默認)和公平鎖，synchronized只支持非公平鎖，當然，在大部分情況下，非公平鎖是高效的選擇。

11、什麼是Executors框架？

Executor框架是一個根據一組執行策略調用，調度，執行和控制的異步任務的框架。

無限制的創建線程會引起應用程序內存溢出。所以創建一個線程池是個更好的的解決方案，因爲可以限制線程的數量並且可以回收再利用這些線程。利用Executors框架可以非常方便的創建一個線程池。

12、什麼是阻塞隊列？阻塞隊列的實現原理是什麼？如何使用阻塞隊列來實現生產者-消費者模型？

阻塞隊列（BlockingQueue）是一個支持兩個附加操作的隊列。

這兩個附加的操作是：在隊列爲空時，獲取元素的線程會等待隊列變爲非空。當隊列滿時，存儲元素的線程會等待隊列可用。

阻塞隊列常用於生產者和消費者的場景，生產者是往隊列裏添加元素的線程，消費者是從隊列裏拿元素的線程。阻塞隊列就是生產者存放元素的容器，而消費者也只從容器裏拿元素。

JDK7提供了7個阻塞隊列。分別是：

ArrayBlockingQueue ：一個由數組結構組成的有界阻塞隊列。

LinkedBlockingQueue ：一個由鏈表結構組成的有界阻塞隊列。

PriorityBlockingQueue ：一個支持優先級排序的無界阻塞隊列。

DelayQueue：一個使用優先級隊列實現的無界阻塞隊列。

SynchronousQueue：一個不存儲元素的阻塞隊列。

LinkedTransferQueue：一個由鏈表結構組成的無界阻塞隊列。

LinkedBlockingDeque：一個由鏈表結構組成的雙向阻塞隊列。

Java 5之前實現同步存取時，可以使用普通的一個集合，然後在使用線程的協作和線程同步可以實現生產者，消費者模式，主要的技術就是用好，wait ,notify,notifyAll,sychronized這些關鍵字。而在java 5之後，可以使用阻塞隊列來實現，此方式大大簡少了代碼量，使得多線程編程更加容易，安全方面也有保障。

BlockingQueue接口是Queue的子接口，它的主要用途並不是作爲容器，而是作爲線程同步的的工具，因此他具有一個很明顯的特性，當生產者線程試圖向BlockingQueue放入元素時，如果隊列已滿，則線程被阻塞，當消費者線程試圖從中取出一個元素時，如果隊列爲空，則該線程會被阻塞，正是因爲它所具有這個特性，所以在程序中多個線程交替向BlockingQueue中放入元素，取出元素，它可以很好的控制線程之間的通信。

阻塞隊列使用最經典的場景就是socket客戶端數據的讀取和解析，讀取數據的線程不斷將數據放入隊列，然後解析線程不斷從隊列取數據解析。

13、什麼是Callable和Future?

Callable接口類似於Runnable，從名字就可以看出來了，但是Runnable不會返回結果，並且無法拋出返回結果的異常，而Callable功能更強大一些，被線程執行後，可以返回值，這個返回值可以被Future拿到，也就是說，Future可以拿到異步執行任務的返回值。

可以認爲是帶有回調的Runnable。

Future接口表示異步任務，是還沒有完成的任務給出的未來結果。所以說Callable用於產生結果，Future用於獲取結果。

14、什麼是FutureTask?

使用ExecutorService啓動任務。

在Java併發程序中FutureTask表示一個可以取消的異步運算。它有啓動和取消運算、查詢運算是否完成和取回運算結果等方法。只有當運算完成的時候結果才能取回，如果運算尚未完成get方法將會阻塞。一個FutureTask對象可以對調用了Callable和Runnable的對象進行包裝，由於FutureTask也是調用了Runnable接口所以它可以提交給Executor來執行。

15、什麼是併發容器的實現？

何爲同步容器：可以簡單地理解爲通過synchronized來實現同步的容器，如果有多個線程調用同步容器的方法，它們將會串行執行。比如Vector，Hashtable，以及Collections.synchronizedSet，synchronizedList等方法返回的容器。

可以通過查看Vector，Hashtable等這些同步容器的實現代碼，可以看到這些容器實現線程安全的方式就是將它們的狀態封裝起來，並在需要同步的方法上加上關鍵字synchronized。

併發容器使用了與同步容器完全不同的加鎖策略來提供更高的併發性和伸縮性，例如在ConcurrentHashMap中採用了一種粒度更細的加鎖機制，可以稱爲分段鎖，在這種鎖機制下，允許任意數量的讀線程併發地訪問map，並且執行讀操作的線程和寫操作的線程也可以併發的訪問map，同時允許一定數量的寫操作線程併發地修改map，所以它可以在併發環境下實現更高的吞吐量。

16、多線程同步和互斥有幾種實現方法，都是什麼？

線程同步是指線程之間所具有的一種制約關係，一個線程的執行依賴另一個線程的消息，當它沒有得到另一個線程的消息時應等待，直到消息到達時才被喚醒。

線程互斥是指對於共享的進程系統資源，在各單個線程訪問時的排它性。當有若干個線程都要使用某一共享資源時，任何時刻最多隻允許一個線程去使用，其它要使用該資源的線程必須等待，直到佔用資源者釋放該資源。線程互斥可以看成是一種特殊的線程同步。

線程間的同步方法大體可分爲兩類：用戶模式和內核模式。顧名思義，內核模式就是指利用系統內核對象的單一性來進行同步，使用時需要切換內核態與用戶態，而用戶模式就是不需要切換到內核態，只在用戶態完成操作。

用戶模式下的方法有：原子操作（例如一個單一的全局變量），臨界區。內核模式下的方法有：事件，信號量，互斥量。

17、什麼是競爭條件？你怎樣發現和解決競爭？

當多個進程都企圖對共享數據進行某種處理，而最後的結果又取決於進程運行的順序時，則我們認爲這發生了競爭條件（race condition）。

18、你將如何使用thread dump？你將如何分析Thread dump？

• 新建狀態（New）
• 用new語句創建的線程處於新建狀態，此時它和其他Java對象一樣，僅僅在堆區中被分配了內存。
• 就緒狀態（Runnable）
• 當一個線程對象創建後，其他線程調用它的start()方法，該線程就進入就緒狀態，Java虛擬機會爲它創建方法調用棧和程序計數器。處於這個狀態的線程位於可運行池中，等待獲得CPU的使用權。
• 運行狀態（Running）
• 處於這個狀態的線程佔用CPU，執行程序代碼。只有處於就緒狀態的線程纔有機會轉到運行狀態。
• 阻塞狀態（Blocked）
• 阻塞狀態是指線程因爲某些原因放棄CPU，暫時停止運行。當線程處於阻塞狀態時，Java虛擬機不會給線程分配CPU。直到線程重新進入就緒狀態，它纔有機會轉到運行狀態。
• 阻塞狀態可分爲以下3種：
• ① 位於對象等待池中的阻塞狀態（Blocked in object’s wait pool）：當線程處於運行狀態時，如果執行了某個對象的wait()方法，Java虛擬機就會把線程放到這個對象的等待池中，這涉及到“線程通信”的內容。
• ② 位於對象鎖池中的阻塞狀態（Blocked in object’s lock pool）：當線程處於運行狀態時，試圖獲得某個對象的同步鎖時，如果該對象的同步鎖已經被其他線程佔用，Java虛擬機就會把這個線程放到這個對象的鎖池中，這涉及到“線程同步”的內容。
• ③ 其他阻塞狀態（Otherwise Blocked）：當前線程執行了sleep()方法，或者調用了其他線程的join()方法，或者發出了I/O請求時，就會進入這個狀態。
• 死亡狀態（Dead）
• 當線程退出run()方法時，就進入死亡狀態，該線程結束生命週期。

我們運行之前的那個死鎖代碼SimpleDeadLock.java，然後嘗試輸出信息(/*這是註釋，作者自己加的*/)：

/* 時間，jvm信息 */
2017-11-01 17:36:28
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.144-b01 mixed mode):
/* 線程名稱：DestroyJavaVM
編號：#13
優先級：5
系統優先級：0
jvm內部線程id：0x0000000001c88800
對應系統線程id（NativeThread ID）：0x1c18
線程狀態： waiting on condition [0x0000000000000000] （等待某個條件）
線程詳細狀態：java.lang.Thread.State: RUNNABLE 及之後所有*/
"DestroyJavaVM" #13 prio=5 os_prio=0 tid=0x0000000001c88800 nid=0x1c18 waiting on condition [0x0000000000000000]
 java.lang.Thread.State: RUNNABLE
"Thread-1" #12 prio=5 os_prio=0 tid=0x0000000018d49000 nid=0x17b8 waiting for monitor entry [0x0000000019d7f000]
/* 線程狀態：阻塞（在對象同步上）
 代碼位置：at com.leo.interview.SimpleDeadLock$B.run(SimpleDeadLock.java:56)
 等待鎖：0x00000000d629b4d8 
 已經獲得鎖：0x00000000d629b4e8*/
 java.lang.Thread.State: BLOCKED (on object monitor)
 at com.leo.interview.SimpleDeadLock$B.run(SimpleDeadLock.java:56)
 - waiting to lock <0x00000000d629b4d8> (a java.lang.Object)
 - locked <0x00000000d629b4e8> (a java.lang.Object)
"Thread-0" #11 prio=5 os_prio=0 tid=0x0000000018d44000 nid=0x1ebc waiting for monitor entry [0x000000001907f000]
 java.lang.Thread.State: BLOCKED (on object monitor)
 at com.leo.interview.SimpleDeadLock$A.run(SimpleDeadLock.java:34)
 - waiting to lock <0x00000000d629b4e8> (a java.lang.Object)
 - locked <0x00000000d629b4d8> (a java.lang.Object)
"Service Thread" #10 daemon prio=9 os_prio=0 tid=0x0000000018ca5000 nid=0x1264 runnable [0x0000000000000000]
 java.lang.Thread.State: RUNNABLE
"C1 CompilerThread2" #9 daemon prio=9 os_prio=2 tid=0x0000000018c46000 nid=0xb8c waiting on condition [0x0000000000000000]
 java.lang.Thread.State: RUNNABLE
"C2 CompilerThread1" #8 daemon prio=9 os_prio=2 tid=0x0000000018be4800 nid=0x1db4 waiting on condition [0x0000000000000000]
 java.lang.Thread.State: RUNNABLE
"C2 CompilerThread0" #7 daemon prio=9 os_prio=2 tid=0x0000000018be3800 nid=0x810 waiting on condition [0x0000000000000000]
 java.lang.Thread.State: RUNNABLE
"Monitor Ctrl-Break" #6 daemon prio=5 os_prio=0 tid=0x0000000018bcc800 nid=0x1c24 runnable [0x00000000193ce000]
 java.lang.Thread.State: RUNNABLE
 at java.net.SocketInputStream.socketRead0(Native Method)
 at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
 at java.net.SocketInputStream.read(SocketInputStream.java:171)
 at java.net.SocketInputStream.read(SocketInputStream.java:141)
 at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
 at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
 at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
 - locked <0x00000000d632b928> (a java.io.InputStreamReader)
 at java.io.InputStreamReader.read(InputStreamReader.java:184)
 at java.io.BufferedReader.fill(BufferedReader.java:161)
 at java.io.BufferedReader.readLine(BufferedReader.java:324)
 - locked <0x00000000d632b928> (a java.io.InputStreamReader)
 at java.io.BufferedReader.readLine(BufferedReader.java:389)
 at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)
"Attach Listener" #5 daemon prio=5 os_prio=2 tid=0x0000000017781800 nid=0x524 runnable [0x0000000000000000]
 java.lang.Thread.State: RUNNABLE
"Signal Dispatcher" #4 daemon prio=9 os_prio=2 tid=0x000000001778f800 nid=0x1b08 waiting on condition [0x0000000000000000]
 java.lang.Thread.State: RUNNABLE
"Finalizer" #3 daemon prio=8 os_prio=1 tid=0x000000001776a800 nid=0xdac in Object.wait() [0x0000000018b6f000]
 java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on <0x00000000d6108ec8> (a java.lang.ref.ReferenceQueue$Lock)
 at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:143)
 - locked <0x00000000d6108ec8> (a java.lang.ref.ReferenceQueue$Lock)
 at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:164)
 at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:209)
"Reference Handler" #2 daemon prio=10 os_prio=2 tid=0x0000000017723800 nid=0x1670 in Object.wait() [0x00000000189ef000]
 java.lang.Thread.State: WAITING (on object monitor)
 at java.lang.Object.wait(Native Method)
 - waiting on <0x00000000d6106b68> (a java.lang.ref.Reference$Lock)
 at java.lang.Object.wait(Object.java:502)
 at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
 - locked <0x00000000d6106b68> (a java.lang.ref.Reference$Lock)
 at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
"VM Thread" os_prio=2 tid=0x000000001771b800 nid=0x604 runnable 
"GC task thread#0 (ParallelGC)" os_prio=0 tid=0x0000000001c9d800 nid=0x9f0 runnable 
"GC task thread#1 (ParallelGC)" os_prio=0 tid=0x0000000001c9f000 nid=0x154c runnable 
"GC task thread#2 (ParallelGC)" os_prio=0 tid=0x0000000001ca0800 nid=0xcd0 runnable 
"GC task thread#3 (ParallelGC)" os_prio=0 tid=0x0000000001ca2000 nid=0x1e58 runnable 
"VM Periodic Task Thread" os_prio=2 tid=0x0000000018c5a000 nid=0x1b58 waiting on condition 
JNI global references: 33
/* 此處可以看待死鎖的相關信息！ */
Found one Java-level deadlock:
=============================
"Thread-1":
 waiting to lock monitor 0x0000000017729fc8 (object 0x00000000d629b4d8, a java.lang.Object),
 which is held by "Thread-0"
"Thread-0":
 waiting to lock monitor 0x0000000017727738 (object 0x00000000d629b4e8, a java.lang.Object),
 which is held by "Thread-1"
Java stack information for the threads listed above:
===================================================
"Thread-1":
 at com.leo.interview.SimpleDeadLock$B.run(SimpleDeadLock.java:56)
 - waiting to lock <0x00000000d629b4d8> (a java.lang.Object)
 - locked <0x00000000d629b4e8> (a java.lang.Object)
"Thread-0":
 at com.leo.interview.SimpleDeadLock$A.run(SimpleDeadLock.java:34)
 - waiting to lock <0x00000000d629b4e8> (a java.lang.Object)
 - locked <0x00000000d629b4d8> (a java.lang.Object)
Found 1 deadlock.
/* 內存使用狀況，詳情得看JVM方面的書 */
Heap
 PSYoungGen total 37888K, used 4590K [0x00000000d6100000, 0x00000000d8b00000, 0x0000000100000000)
 eden space 32768K, 14% used [0x00000000d6100000,0x00000000d657b968,0x00000000d8100000)
 from space 5120K, 0% used [0x00000000d8600000,0x00000000d8600000,0x00000000d8b00000)
 to space 5120K, 0% used [0x00000000d8100000,0x00000000d8100000,0x00000000d8600000)
 ParOldGen total 86016K, used 0K [0x0000000082200000, 0x0000000087600000, 0x00000000d6100000)
 object space 86016K, 0% used [0x0000000082200000,0x0000000082200000,0x0000000087600000)
 Metaspace used 3474K, capacity 4500K, committed 4864K, reserved 1056768K
 class space used 382K, capacity 388K, committed 512K, reserved 1048576K

19、爲什麼我們調用start()方法時會執行run()方法，爲什麼我們不能直接調用run()方法？

當你調用start()方法時你將創建新的線程，並且執行在run()方法裏的代碼。

但是如果你直接調用run()方法，它不會創建新的線程也不會執行調用線程的代碼，只會把run方法當作普通方法去執行。

20、Java中你怎樣喚醒一個阻塞的線程？

在Java發展史上曾經使用suspend()、resume()方法對於線程進行阻塞喚醒，但隨之出現很多問題，比較典型的還是死鎖問題。

解決方案可以使用以對象爲目標的阻塞，即利用Object類的wait()和notify()方法實現線程阻塞。

首先，wait、notify方法是針對對象的，調用任意對象的wait()方法都將導致線程阻塞，阻塞的同時也將釋放該對象的鎖，相應地，調用任意對象的notify()方法則將隨機解除該對象阻塞的線程，但它需要重新獲取改對象的鎖，直到獲取成功才能往下執行；其次，wait、notify方法必須在synchronized塊或方法中被調用，並且要保證同步塊或方法的鎖對象與調用wait、notify方法的對象是同一個，如此一來在調用wait之前當前線程就已經成功獲取某對象的鎖，執行wait阻塞後當前線程就將之前獲取的對象鎖釋放。

21、在Java中CycliBarriar和

CountdownLatch有什麼區別？

CyclicBarrier可以重複使用，而CountdownLatch不能重複使用。

Java的concurrent包裏面的CountDownLatch其實可以把它看作一個計數器，只不過這個計數器的操作是原子操作，同時只能有一個線程去操作這個計數器，也就是同時只能有一個線程去減這個計數器裏面的值。

你可以向CountDownLatch對象設置一個初始的數字作爲計數值，任何調用這個對象上的await()方法都會阻塞，直到這個計數器的計數值被其他的線程減爲0爲止。

所以在當前計數到達零之前，await 方法會一直受阻塞。之後，會釋放所有等待的線程，await的所有後續調用都將立即返回。這種現象只出現一次——計數無法被重置。如果需要重置計數，請考慮使用 CyclicBarrier。

CountDownLatch的一個非常典型的應用場景是：有一個任務想要往下執行，但必須要等到其他的任務執行完畢後纔可以繼續往下執行。假如我們這個想要繼續往下執行的任務調用一個CountDownLatch對象的await()方法，其他的任務執行完自己的任務後調用同一個CountDownLatch對象上的countDown()方法，這個調用await()方法的任務將一直阻塞等待，直到這個CountDownLatch對象的計數值減到0爲止

CyclicBarrier一個同步輔助類，它允許一組線程互相等待，直到到達某個公共屏障點 (common barrier point)。在涉及一組固定大小的線程的程序中，這些線程必須不時地互相等待，此時 CyclicBarrier 很有用。因爲該 barrier 在釋放等待線程後可以重用，所以稱它爲循環 的 barrier。

22、什麼是不可變對象，它對寫併發應用有什麼幫助？

不可變對象(Immutable Objects)即對象一旦被創建它的狀態（對象的數據，也即對象屬性值）就不能改變，反之即爲可變對象(Mutable Objects)。

不可變對象的類即爲不可變類(Immutable Class)。Java平臺類庫中包含許多不可變類，如String、基本類型的包裝類、BigInteger和BigDecimal等。

不可變對象天生是線程安全的。它們的常量（域）是在構造函數中創建的。既然它們的狀態無法修改，這些常量永遠不會變。

不可變對象永遠是線程安全的。

只有滿足如下狀態，一個對象纔是不可變的；

• 它的狀態不能在創建後再被修改；
• 所有域都是final類型；並且，
• 它被正確創建（創建期間沒有發生this引用的逸出）。

23、什麼是多線程中的上下文切換？

在上下文切換過程中，CPU會停止處理當前運行的程序，並保存當前程序運行的具體位置以便之後繼續運行。從這個角度來看，上下文切換有點像我們同時閱讀幾本書，在來回切換書本的同時我們需要記住每本書當前讀到的頁碼。在程序中，上下文切換過程中的“頁碼”信息是保存在進程控制塊（PCB）中的。PCB還經常被稱作“切換楨”（switchframe）。“頁碼”信息會一直保存到CPU的內存中，直到他們被再次使用。

上下文切換是存儲和恢復CPU狀態的過程，它使得線程執行能夠從中斷點恢復執行。上下文切換是多任務操作系統和多線程環境的基本特徵。

24、Java中用到的線程調度算法是什麼？

計算機通常只有一個CPU,在任意時刻只能執行一條機器指令,每個線程只有獲得CPU的使用權才能執行指令.所謂多線程的併發運行,其實是指從宏觀上看,各個線程輪流獲得CPU的使用權,分別執行各自的任務.在運行池中,會有多個處於就緒狀態的線程在等待CPU,JAVA虛擬機的一項任務就是負責線程的調度,線程調度是指按照特定機製爲多個線程分配CPU的使用權.

有兩種調度模型：分時調度模型和搶佔式調度模型。

分時調度模型是指讓所有的線程輪流獲得cpu的使用權,並且平均分配每個線程佔用的CPU的時間片這個也比較好理解。

java虛擬機採用搶佔式調度模型，是指優先讓可運行池中優先級高的線程佔用CPU，如果可運行池中的線程優先級相同，那麼就隨機選擇一個線程，使其佔用CPU。處於運行狀態的線程會一直運行，直至它不得不放棄CPU。

25、什麼是線程組，爲什麼在Java中不推薦使用？

線程組和線程池是兩個不同的概念，他們的作用完全不同，前者是爲了方便線程的管理，後者是爲了管理線程的生命週期，複用線程，減少創建銷燬線程的開銷。

26、爲什麼使用Executor框架比使用應用創建和管理線程好？

爲什麼要使用Executor線程池框架

1. 每次執行任務創建線程 new Thread()比較消耗性能，創建一個線程是比較耗時、耗資源的。
2. 調用 new Thread()創建的線程缺乏管理，被稱爲野線程，而且可以無限制的創建，線程之間的相互競爭會導致過多佔用系統資源而導致系統癱瘓，還有線程之間的頻繁交替也會消耗很多系統資源。
3. 直接使用new Thread() 啓動的線程不利於擴展，比如定時執行、定期執行、定時定期執行、線程中斷等都不便實現。

使用Executor線程池框架的優點

1. 能複用已存在並空閒的線程從而減少線程對象的創建從而減少了消亡線程的開銷。
2. 可有效控制最大併發線程數，提高系統資源使用率，同時避免過多資源競爭。
3. 框架中已經有定時、定期、單線程、併發數控制等功能。

綜上所述使用線程池框架Executor能更好的管理線程、提供系統資源使用率。

27、java中有幾種方法可以實現一個線程？

• 繼承 Thread 類
• 實現 Runnable 接口
• 實現 Callable 接口，需要實現的是 call() 方法

28、如何停止一個正在運行的線程？

• 使用共享變量的方式
• 在這種方式中，之所以引入共享變量，是因爲該變量可以被多個執行相同任務的線程用來作爲是否中斷的信號，通知中斷線程的執行。
• 使用interrupt方法終止線程
• 如果一個線程由於等待某些事件的發生而被阻塞，又該怎樣停止該線程呢？這種情況經常會發生，比如當一個線程由於需要等候鍵盤輸入而被阻塞，或者調用Thread.join()方法，或者Thread.sleep()方法，在網絡中調用ServerSocket.accept()方法，或者調用了DatagramSocket.receive()方法時，都有可能導致線程阻塞，使線程處於處於不可運行狀態時，即使主程序中將該線程的共享變量設置爲true，但該線程此時根本無法檢查循環標誌，當然也就無法立即中斷。這裏我們給出的建議是，不要使用stop()方法，而是使用Thread提供的interrupt()方法，因爲該方法雖然不會中斷一個正在運行的線程，但是它可以使一個被阻塞的線程拋出一箇中斷異常，從而使線程提前結束阻塞狀態，退出堵塞代碼。

29、notify()和notifyAll()有什麼區別？

當一個線程進入wait之後，就必須等其他線程notify/notifyall,使用notifyall,可以喚醒所有處於wait狀態的線程，使其重新進入鎖的爭奪隊列中，而notify只能喚醒一個。

如果沒把握，建議notifyAll，防止notigy因爲信號丟失而造成程序異常。

30、什麼是Daemon線程？它有什麼意義？

所謂後臺(daemon)線程，是指在程序運行的時候在後臺提供一種通用服務的線程，並且這個線程並不屬於程序中不可或缺的部分。因此，當所有的非後臺線程結束時，程序也就終止了，同時會殺死進程中的所有後臺線程。

反過來說， 只要有任何非後臺線程還在運行，程序就不會終止。必須在線程啓動之前調用setDaemon()方法，才能把它設置爲後臺線程。注意：後臺進程在不執行finally子句的情況下就會終止其run()方法。

比如：JVM的垃圾回收線程就是Daemon線程，Finalizer也是守護線程。

31、java如何實現多線程之間的通訊和協作？

中斷和共享變量