當(dāng)前位置：首頁 > 编程语言 > java >内容正文

java

Java并发编程面试题（2020最新版）

發(fā)布時間：2023/12/3 java 28 豆豆

生活随笔收集整理的這篇文章主要介紹了 Java并发编程面试题（2020最新版）小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

轉(zhuǎn)載自??Java并發(fā)編程面試題（2020最新版）

基礎(chǔ)知識

并發(fā)編程的優(yōu)缺點(diǎn)

為什么要使用并發(fā)編程（并發(fā)編程的優(yōu)點(diǎn)）

充分利用多核CPU的計(jì)算能力：通過并發(fā)編程的形式可以將多核CPU的計(jì)算能力發(fā)揮到極致，性能得到提升

?
方便進(jìn)行業(yè)務(wù)拆分，提升系統(tǒng)并發(fā)能力和性能：在特殊的業(yè)務(wù)場景下，先天的就適合于并發(fā)編程。現(xiàn)在的系統(tǒng)動不動就要求百萬級甚至千萬級的并發(fā)量，而多線程并發(fā)編程正是開發(fā)高并發(fā)系統(tǒng)的基礎(chǔ)，利用好多線程機(jī)制可以大大提高系統(tǒng)整體的并發(fā)能力以及性能。面對復(fù)雜業(yè)務(wù)模型，并行程序會比串行程序更適應(yīng)業(yè)務(wù)需求，而并發(fā)編程更能吻合這種業(yè)務(wù)拆分。

并發(fā)編程有什么缺點(diǎn)

并發(fā)編程的目的就是為了能提高程序的執(zhí)行效率，提高程序運(yùn)行速度，但是并發(fā)編程并不總是能提高程序運(yùn)行速度的，而且并發(fā)編程可能會遇到很多問題，比如**：內(nèi)存泄漏、上下文切換、線程安全、死鎖**等問題。

并發(fā)編程三要素是什么？在 Java 程序中怎么保證多線程的運(yùn)行安全？

并發(fā)編程三要素（線程的安全性問題體現(xiàn)在）：

原子性：原子，即一個不可再被分割的顆粒。原子性指的是一個或多個操作要么全部執(zhí)行成功要么全部執(zhí)行失敗。

可見性：一個線程對共享變量的修改,另一個線程能夠立刻看到。（synchronized,volatile）

有序性：程序執(zhí)行的順序按照代碼的先后順序執(zhí)行。（處理器可能會對指令進(jìn)行重排序）

出現(xiàn)線程安全問題的原因：

線程切換帶來的原子性問題
緩存導(dǎo)致的可見性問題
編譯優(yōu)化帶來的有序性問題

解決辦法：

JDK Atomic開頭的原子類、synchronized、LOCK，可以解決原子性問題
synchronized、volatile、LOCK，可以解決可見性問題
Happens-Before 規(guī)則可以解決有序性問題

并行和并發(fā)有什么區(qū)別？

并發(fā)：多個任務(wù)在同一個 CPU 核上，按細(xì)分的時間片輪流(交替)執(zhí)行，從邏輯上來看那些任務(wù)是同時執(zhí)行。
并行：單位時間內(nèi)，多個處理器或多核處理器同時處理多個任務(wù)，是真正意義上的“同時進(jìn)行”。
串行：有n個任務(wù)，由一個線程按順序執(zhí)行。由于任務(wù)、方法都在一個線程執(zhí)行所以不存在線程不安全情況，也就不存在臨界區(qū)的問題。

做一個形象的比喻：

并發(fā) = 兩個隊(duì)列和一臺咖啡機(jī)。

并行 = 兩個隊(duì)列和兩臺咖啡機(jī)。

串行 = 一個隊(duì)列和一臺咖啡機(jī)。

什么是多線程，多線程的優(yōu)劣？

多線程：多線程是指程序中包含多個執(zhí)行流，即在一個程序中可以同時運(yùn)行多個不同的線程來執(zhí)行不同的任務(wù)。

多線程的好處：

可以提高 CPU 的利用率。在多線程程序中，一個線程必須等待的時候，CPU 可以運(yùn)行其它的線程而不是等待，這樣就大大提高了程序的效率。也就是說允許單個程序創(chuàng)建多個并行執(zhí)行的線程來完成各自的任務(wù)。

多線程的劣勢：

線程也是程序，所以線程需要占用內(nèi)存，線程越多占用內(nèi)存也越多；
多線程需要協(xié)調(diào)和管理，所以需要 CPU 時間跟蹤線程；
線程之間對共享資源的訪問會相互影響，必須解決競用共享資源的問題。

線程和進(jìn)程區(qū)別

什么是線程和進(jìn)程?

進(jìn)程

一個在內(nèi)存中運(yùn)行的應(yīng)用程序。每個進(jìn)程都有自己獨(dú)立的一塊內(nèi)存空間，一個進(jìn)程可以有多個線程，比如在Windows系統(tǒng)中，一個運(yùn)行的xx.exe就是一個進(jìn)程。

線程

進(jìn)程中的一個執(zhí)行任務(wù)（控制單元），負(fù)責(zé)當(dāng)前進(jìn)程中程序的執(zhí)行。一個進(jìn)程至少有一個線程，一個進(jìn)程可以運(yùn)行多個線程，多個線程可共享數(shù)據(jù)。

進(jìn)程與線程的區(qū)別

線程具有許多傳統(tǒng)進(jìn)程所具有的特征，故又稱為輕型進(jìn)程(Light—Weight Process)或進(jìn)程元；而把傳統(tǒng)的進(jìn)程稱為重型進(jìn)程(Heavy—Weight Process)，它相當(dāng)于只有一個線程的任務(wù)。在引入了線程的操作系統(tǒng)中，通常一個進(jìn)程都有若干個線程，至少包含一個線程。

根本區(qū)別：進(jìn)程是操作系統(tǒng)資源分配的基本單位，而線程是處理器任務(wù)調(diào)度和執(zhí)行的基本單位

資源開銷：每個進(jìn)程都有獨(dú)立的代碼和數(shù)據(jù)空間（程序上下文），程序之間的切換會有較大的開銷；線程可以看做輕量級的進(jìn)程，同一類線程共享代碼和數(shù)據(jù)空間，每個線程都有自己獨(dú)立的運(yùn)行棧和程序計(jì)數(shù)器（PC），線程之間切換的開銷小。

包含關(guān)系：如果一個進(jìn)程內(nèi)有多個線程，則執(zhí)行過程不是一條線的，而是多條線（線程）共同完成的；線程是進(jìn)程的一部分，所以線程也被稱為輕權(quán)進(jìn)程或者輕量級進(jìn)程。

內(nèi)存分配：同一進(jìn)程的線程共享本進(jìn)程的地址空間和資源，而進(jìn)程之間的地址空間和資源是相互獨(dú)立的

影響關(guān)系：一個進(jìn)程崩潰后，在保護(hù)模式下不會對其他進(jìn)程產(chǎn)生影響，但是一個線程崩潰整個進(jìn)程都死掉。所以多進(jìn)程要比多線程健壯。

執(zhí)行過程：每個獨(dú)立的進(jìn)程有程序運(yùn)行的入口、順序執(zhí)行序列和程序出口。但是線程不能獨(dú)立執(zhí)行，必須依存在應(yīng)用程序中，由應(yīng)用程序提供多個線程執(zhí)行控制，兩者均可并發(fā)執(zhí)行

什么是上下文切換?

多線程編程中一般線程的個數(shù)都大于 CPU 核心的個數(shù)，而一個 CPU 核心在任意時刻只能被一個線程使用，為了讓這些線程都能得到有效執(zhí)行，CPU 采取的策略是為每個線程分配時間片并輪轉(zhuǎn)的形式。當(dāng)一個線程的時間片用完的時候就會重新處于就緒狀態(tài)讓給其他線程使用，這個過程就屬于一次上下文切換。

概括來說就是：當(dāng)前任務(wù)在執(zhí)行完 CPU 時間片切換到另一個任務(wù)之前會先保存自己的狀態(tài)，以便下次再切換回這個任務(wù)時，可以再加載這個任務(wù)的狀態(tài)。任務(wù)從保存到再加載的過程就是一次上下文切換。

上下文切換通常是計(jì)算密集型的。也就是說，它需要相當(dāng)可觀的處理器時間，在每秒幾十上百次的切換中，每次切換都需要納秒量級的時間。所以，上下文切換對系統(tǒng)來說意味著消耗大量的 CPU 時間，事實(shí)上，可能是操作系統(tǒng)中時間消耗最大的操作。

Linux 相比與其他操作系統(tǒng)（包括其他類 Unix 系統(tǒng)）有很多的優(yōu)點(diǎn)，其中有一項(xiàng)就是，其上下文切換和模式切換的時間消耗非常少。

守護(hù)線程和用戶線程有什么區(qū)別呢？

守護(hù)線程和用戶線程

用戶 (User) 線程：運(yùn)行在前臺，執(zhí)行具體的任務(wù)，如程序的主線程、連接網(wǎng)絡(luò)的子線程等都是用戶線程
守護(hù) (Daemon) 線程：運(yùn)行在后臺，為其他前臺線程服務(wù)。也可以說守護(hù)線程是 JVM 中非守護(hù)線程的?“傭人”。一旦所有用戶線程都結(jié)束運(yùn)行，守護(hù)線程會隨 JVM 一起結(jié)束工作

main 函數(shù)所在的線程就是一個用戶線程啊，main 函數(shù)啟動的同時在 JVM 內(nèi)部同時還啟動了好多守護(hù)線程，比如垃圾回收線程。

比較明顯的區(qū)別之一是用戶線程結(jié)束，JVM 退出，不管這個時候有沒有守護(hù)線程運(yùn)行。而守護(hù)線程不會影響 JVM 的退出。

注意事項(xiàng)：

setDaemon(true)必須在start()方法前執(zhí)行，否則會拋出 IllegalThreadStateException 異常

在守護(hù)線程中產(chǎn)生的新線程也是守護(hù)線程

不是所有的任務(wù)都可以分配給守護(hù)線程來執(zhí)行，比如讀寫操作或者計(jì)算邏輯

守護(hù) (Daemon) 線程中不能依靠 finally 塊的內(nèi)容來確保執(zhí)行關(guān)閉或清理資源的邏輯。因?yàn)槲覀兩厦嬉舱f過了一旦所有用戶線程都結(jié)束運(yùn)行，守護(hù)線程會隨 JVM 一起結(jié)束工作，所以守護(hù) (Daemon) 線程中的 finally 語句塊可能無法被執(zhí)行。

如何在 Windows 和 Linux 上查找哪個線程cpu利用率最高？

windows上面用任務(wù)管理器看，linux下可以用 top 這個工具看。

找出cpu耗用厲害的進(jìn)程pid，終端執(zhí)行top命令，然后按下shift+p 查找出cpu利用最厲害的pid號
根據(jù)上面第一步拿到的pid號，top -H -p pid 。然后按下shift+p，查找出cpu利用率最厲害的線程號，比如top -H -p 1328
將獲取到的線程號轉(zhuǎn)換成16進(jìn)制，去百度轉(zhuǎn)換一下就行
使用jstack工具將進(jìn)程信息打印輸出，jstack pid號 > /tmp/t.dat，比如jstack 31365 > /tmp/t.dat
編輯/tmp/t.dat文件，查找線程號對應(yīng)的信息

什么是線程死鎖

百度百科：死鎖是指兩個或兩個以上的進(jìn)程（線程）在執(zhí)行過程中，由于競爭資源或者由于彼此通信而造成的一種阻塞的現(xiàn)象，若無外力作用，它們都將無法推進(jìn)下去。此時稱系統(tǒng)處于死鎖狀態(tài)或系統(tǒng)產(chǎn)生了死鎖，這些永遠(yuǎn)在互相等待的進(jìn)程（線程）稱為死鎖進(jìn)程（線程）。

多個線程同時被阻塞，它們中的一個或者全部都在等待某個資源被釋放。由于線程被無限期地阻塞，因此程序不可能正常終止。

如下圖所示，線程 A 持有資源 2，線程 B 持有資源 1，他們同時都想申請對方的資源，所以這兩個線程就會互相等待而進(jìn)入死鎖狀態(tài)。

下面通過一個例子來說明線程死鎖，代碼模擬了上圖的死鎖的情況 (代碼來源于《并發(fā)編程之美》)：

public class DeadLockDemo { private static Object resource1 = new Object();//資源 1 private static Object resource2 = new Object();//資源 2 public static void main(String[] args) { new Thread(() -> { synchronized (resource1) { System.out.println(Thread.currentThread() + "get resource1"); try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println(Thread.currentThread() + "waiting get resource2"); synchronized (resource2) { System.out.println(Thread.currentThread() + "get resource2"); } } }, "線程 1").start(); new Thread(() -> { synchronized (resource2) { System.out.println(Thread.currentThread() + "get resource2"); try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println(Thread.currentThread() + "waiting get resource1"); synchronized (resource1) { System.out.println(Thread.currentThread() + "get resource1"); } } }, "線程 2").start(); }}

輸出結(jié)果

Thread[線程 1,5,main]get resource1Thread[線程 2,5,main]get resource2Thread[線程 1,5,main]waiting get resource2Thread[線程 2,5,main]waiting get resource1

線程 A 通過 synchronized (resource1) 獲得 resource1 的監(jiān)視器鎖，然后通過Thread.sleep(1000)；讓線程 A 休眠 1s 為的是讓線程 B 得到CPU執(zhí)行權(quán)，然后獲取到 resource2 的監(jiān)視器鎖。線程 A 和線程 B 休眠結(jié)束了都開始企圖請求獲取對方的資源，然后這兩個線程就會陷入互相等待的狀態(tài)，這也就產(chǎn)生了死鎖。上面的例子符合產(chǎn)生死鎖的四個必要條件。

形成死鎖的四個必要條件是什么

互斥條件：線程(進(jìn)程)對于所分配到的資源具有排它性，即一個資源只能被一個線程(進(jìn)程)占用，直到被該線程(進(jìn)程)釋放
請求與保持條件：一個線程(進(jìn)程)因請求被占用資源而發(fā)生阻塞時，對已獲得的資源保持不放。
不剝奪條件：線程(進(jìn)程)已獲得的資源在末使用完之前不能被其他線程強(qiáng)行剝奪，只有自己使用完畢后才釋放資源。
循環(huán)等待條件：當(dāng)發(fā)生死鎖時，所等待的線程(進(jìn)程)必定會形成一個環(huán)路（類似于死循環(huán)），造成永久阻塞

如何避免線程死鎖

我們只要破壞產(chǎn)生死鎖的四個條件中的其中一個就可以了。

破壞互斥條件

這個條件我們沒有辦法破壞，因?yàn)槲覀冇面i本來就是想讓他們互斥的（臨界資源需要互斥訪問）。

破壞請求與保持條件

一次性申請所有的資源。

破壞不剝奪條件

占用部分資源的線程進(jìn)一步申請其他資源時，如果申請不到，可以主動釋放它占有的資源。

破壞循環(huán)等待條件

靠按序申請資源來預(yù)防。按某一順序申請資源，釋放資源則反序釋放。破壞循環(huán)等待條件。

我們對線程 2 的代碼修改成下面這樣就不會產(chǎn)生死鎖了。

new Thread(() -> { synchronized (resource1) { System.out.println(Thread.currentThread() + "get resource1"); try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); } System.out.println(Thread.currentThread() + "waiting get resource2"); synchronized (resource2) { System.out.println(Thread.currentThread() + "get resource2"); } }}, "線程 2").start();

輸出結(jié)果

Thread[線程 1,5,main]get resource1Thread[線程 1,5,main]waiting get resource2Thread[線程 1,5,main]get resource2Thread[線程 2,5,main]get resource1Thread[線程 2,5,main]waiting get resource2Thread[線程 2,5,main]get resource2

我們分析一下上面的代碼為什么避免了死鎖的發(fā)生?

線程 1 首先獲得到 resource1 的監(jiān)視器鎖，這時候線程 2 就獲取不到了。然后線程 1 再去獲取 resource2 的監(jiān)視器鎖，可以獲取到。然后線程 1 釋放了對 resource1、resource2 的監(jiān)視器鎖的占用，線程 2 獲取到就可以執(zhí)行了。這樣就破壞了破壞循環(huán)等待條件，因此避免了死鎖。

創(chuàng)建線程的四種方式

創(chuàng)建線程有哪幾種方式？

創(chuàng)建線程有四種方式：

繼承 Thread 類；
實(shí)現(xiàn) Runnable 接口；
實(shí)現(xiàn) Callable 接口；
使用 Executors 工具類創(chuàng)建線程池

繼承 Thread 類

步驟

定義一個Thread類的子類，重寫run方法，將相關(guān)邏輯實(shí)現(xiàn)，run()方法就是線程要執(zhí)行的業(yè)務(wù)邏輯方法

創(chuàng)建自定義的線程子類對象

調(diào)用子類實(shí)例的star()方法來啟動線程

public class MyThread extends Thread { @Override public void run() { System.out.println(Thread.currentThread().getName() + " run()方法正在執(zhí)行..."); } }

public class TheadTest { public static void main(String[] args) { MyThread myThread = new MyThread(); myThread.start(); System.out.println(Thread.currentThread().getName() + " main()方法執(zhí)行結(jié)束"); } }

運(yùn)行結(jié)果

main main()方法執(zhí)行結(jié)束Thread-0 run()方法正在執(zhí)行...

實(shí)現(xiàn) Runnable 接口

步驟

定義Runnable接口實(shí)現(xiàn)類MyRunnable，并重寫run()方法

創(chuàng)建MyRunnable實(shí)例myRunnable，以myRunnable作為target創(chuàng)建Thead對象，該Thread對象才是真正的線程對象

調(diào)用線程對象的start()方法

public class MyRunnable implements Runnable { @Override public void run() { System.out.println(Thread.currentThread().getName() + " run()方法執(zhí)行中..."); } }

public class RunnableTest { public static void main(String[] args) { MyRunnable myRunnable = new MyRunnable(); Thread thread = new Thread(myRunnable); thread.start(); System.out.println(Thread.currentThread().getName() + " main()方法執(zhí)行完成"); } }

執(zhí)行結(jié)果

main main()方法執(zhí)行完成Thread-0 run()方法執(zhí)行中...

實(shí)現(xiàn) Callable 接口

步驟

創(chuàng)建實(shí)現(xiàn)Callable接口的類myCallable

以myCallable為參數(shù)創(chuàng)建FutureTask對象

將FutureTask作為參數(shù)創(chuàng)建Thread對象

調(diào)用線程對象的start()方法

public class MyCallable implements Callable<Integer> { @Override public Integer call() { System.out.println(Thread.currentThread().getName() + " call()方法執(zhí)行中..."); return 1; } }

public class CallableTest { public static void main(String[] args) { FutureTask<Integer> futureTask = new FutureTask<Integer>(new MyCallable()); Thread thread = new Thread(futureTask); thread.start(); try { Thread.sleep(1000); System.out.println("返回結(jié)果 " + futureTask.get()); } catch (InterruptedException e) { e.printStackTrace(); } catch (ExecutionException e) { e.printStackTrace(); } System.out.println(Thread.currentThread().getName() + " main()方法執(zhí)行完成"); } }

執(zhí)行結(jié)果

Thread-0 call()方法執(zhí)行中...返回結(jié)果 1main main()方法執(zhí)行完成

使用 Executors 工具類創(chuàng)建線程池

Executors提供了一系列工廠方法用于創(chuàng)先線程池，返回的線程池都實(shí)現(xiàn)了ExecutorService接口。

主要有newFixedThreadPool，newCachedThreadPool，newSingleThreadExecutor，newScheduledThreadPool，后續(xù)詳細(xì)介紹這四種線程池

public class MyRunnable implements Runnable { @Override public void run() { System.out.println(Thread.currentThread().getName() + " run()方法執(zhí)行中..."); } }

public class SingleThreadExecutorTest { public static void main(String[] args) { ExecutorService executorService = Executors.newSingleThreadExecutor(); MyRunnable runnableTest = new MyRunnable(); for (int i = 0; i < 5; i++) { executorService.execute(runnableTest); } System.out.println("線程任務(wù)開始執(zhí)行"); executorService.shutdown(); } }

執(zhí)行結(jié)果

線程任務(wù)開始執(zhí)行pool-1-thread-1 is running...pool-1-thread-1 is running...pool-1-thread-1 is running...pool-1-thread-1 is running...pool-1-thread-1 is running...

說一下 runnable 和 callable 有什么區(qū)別？

相同點(diǎn)

都是接口
都可以編寫多線程程序
都采用Thread.start()啟動線程

主要區(qū)別

Runnable 接口 run 方法無返回值；Callable 接口 call 方法有返回值，是個泛型，和Future、FutureTask配合可以用來獲取異步執(zhí)行的結(jié)果
Runnable 接口 run 方法只能拋出運(yùn)行時異常，且無法捕獲處理；Callable 接口 call 方法允許拋出異常，可以獲取異常信息

注：Callalbe接口支持返回執(zhí)行結(jié)果，需要調(diào)用FutureTask.get()得到，此方法會阻塞主進(jìn)程的繼續(xù)往下執(zhí)行，如果不調(diào)用不會阻塞。

線程的 run()和 start()有什么區(qū)別？

每個線程都是通過某個特定Thread對象所對應(yīng)的方法run()來完成其操作的，run()方法稱為線程體。通過調(diào)用Thread類的start()方法來啟動一個線程。

start() 方法用于啟動線程，run() 方法用于執(zhí)行線程的運(yùn)行時代碼。run() 可以重復(fù)調(diào)用，而 start() 只能調(diào)用一次。

start()方法來啟動一個線程，真正實(shí)現(xiàn)了多線程運(yùn)行。調(diào)用start()方法無需等待run方法體代碼執(zhí)行完畢，可以直接繼續(xù)執(zhí)行其他的代碼；此時線程是處于就緒狀態(tài)，并沒有運(yùn)行。然后通過此Thread類調(diào)用方法run()來完成其運(yùn)行狀態(tài)， run()方法運(yùn)行結(jié)束，此線程終止。然后CPU再調(diào)度其它線程。

run()方法是在本線程里的，只是線程里的一個函數(shù)，而不是多線程的。如果直接調(diào)用run()，其實(shí)就相當(dāng)于是調(diào)用了一個普通函數(shù)而已，直接待用run()方法必須等待run()方法執(zhí)行完畢才能執(zhí)行下面的代碼，所以執(zhí)行路徑還是只有一條，根本就沒有線程的特征，所以在多線程執(zhí)行時要使用start()方法而不是run()方法。

為什么我們調(diào)用 start() 方法時會執(zhí)行 run() 方法，為什么我們不能直接調(diào)用 run() 方法？

這是另一個非常經(jīng)典的 java 多線程面試問題，而且在面試中會經(jīng)常被問到。很簡單，但是很多人都會答不上來！

new 一個 Thread，線程進(jìn)入了新建狀態(tài)。調(diào)用 start() 方法，會啟動一個線程并使線程進(jìn)入了就緒狀態(tài)，當(dāng)分配到時間片后就可以開始運(yùn)行了。start() 會執(zhí)行線程的相應(yīng)準(zhǔn)備工作，然后自動執(zhí)行 run() 方法的內(nèi)容，這是真正的多線程工作。

而直接執(zhí)行 run() 方法，會把 run 方法當(dāng)成一個 main 線程下的普通方法去執(zhí)行，并不會在某個線程中執(zhí)行它，所以這并不是多線程工作。

總結(jié)：調(diào)用 start 方法方可啟動線程并使線程進(jìn)入就緒狀態(tài)，而 run 方法只是 thread 的一個普通方法調(diào)用，還是在主線程里執(zhí)行。

什么是 Callable 和 Future?

Callable 接口類似于 Runnable，從名字就可以看出來了，但是 Runnable 不會返回結(jié)果，并且無法拋出返回結(jié)果的異常，而 Callable 功能更強(qiáng)大一些，被線程執(zhí)行后，可以返回值，這個返回值可以被 Future 拿到，也就是說，Future 可以拿到異步執(zhí)行任務(wù)的返回值。

Future 接口表示異步任務(wù)，是一個可能還沒有完成的異步任務(wù)的結(jié)果。所以說 Callable用于產(chǎn)生結(jié)果，Future 用于獲取結(jié)果。

什么是 FutureTask

FutureTask 表示一個異步運(yùn)算的任務(wù)。FutureTask 里面可以傳入一個 Callable 的具體實(shí)現(xiàn)類，可以對這個異步運(yùn)算的任務(wù)的結(jié)果進(jìn)行等待獲取、判斷是否已經(jīng)完成、取消任務(wù)等操作。只有當(dāng)運(yùn)算完成的時候結(jié)果才能取回，如果運(yùn)算尚未完成 get 方法將會阻塞。一個 FutureTask 對象可以對調(diào)用了 Callable 和 Runnable 的對象進(jìn)行包裝，由于 FutureTask 也是Runnable 接口的實(shí)現(xiàn)類，所以 FutureTask 也可以放入線程池中。

線程的狀態(tài)和基本操作

說說線程的生命周期及五種基本狀態(tài)？

新建(new)：新創(chuàng)建了一個線程對象。

?
可運(yùn)行(runnable)：線程對象創(chuàng)建后，當(dāng)調(diào)用線程對象的 start()方法，該線程處于就緒狀態(tài)，等待被線程調(diào)度選中，獲取cpu的使用權(quán)。

?
運(yùn)行(running)：可運(yùn)行狀態(tài)(runnable)的線程獲得了cpu時間片（timeslice），執(zhí)行程序代碼。注：就緒狀態(tài)是進(jìn)入到運(yùn)行狀態(tài)的唯一入口，也就是說，線程要想進(jìn)入運(yùn)行狀態(tài)執(zhí)行，首先必須處于就緒狀態(tài)中；

?
阻塞(block)：處于運(yùn)行狀態(tài)中的線程由于某種原因，暫時放棄對 CPU的使用權(quán)，停止執(zhí)行，此時進(jìn)入阻塞狀態(tài)，直到其進(jìn)入到就緒狀態(tài)，才有機(jī)會再次被 CPU 調(diào)用以進(jìn)入到運(yùn)行狀態(tài)。

?

阻塞的情況分三種：

(一). 等待阻塞：運(yùn)行狀態(tài)中的線程執(zhí)行 wait()方法，JVM會把該線程放入等待隊(duì)列(waitting queue)中，使本線程進(jìn)入到等待阻塞狀態(tài)；

(二). 同步阻塞：線程在獲取 synchronized 同步鎖失敗(因?yàn)殒i被其它線程所占用)，，則JVM會把該線程放入鎖池(lock pool)中，線程會進(jìn)入同步阻塞狀態(tài)；

(三). 其他阻塞: 通過調(diào)用線程的 sleep()或 join()或發(fā)出了 I/O 請求時，線程會進(jìn)入到阻塞狀態(tài)。當(dāng) sleep()狀態(tài)超時、join()等待線程終止或者超時、或者 I/O 處理完畢時，線程重新轉(zhuǎn)入就緒狀態(tài)。

?
死亡(dead)：線程run()、main()方法執(zhí)行結(jié)束，或者因異常退出了run()方法，則該線程結(jié)束生命周期。死亡的線程不可再次復(fù)生。

Java 中用到的線程調(diào)度算法是什么？

計(jì)算機(jī)通常只有一個 CPU，在任意時刻只能執(zhí)行一條機(jī)器指令，每個線程只有獲得CPU 的使用權(quán)才能執(zhí)行指令。所謂多線程的并發(fā)運(yùn)行，其實(shí)是指從宏觀上看，各個線程輪流獲得 CPU 的使用權(quán)，分別執(zhí)行各自的任務(wù)。在運(yùn)行池中，會有多個處于就緒狀態(tài)的線程在等待 CPU，JAVA 虛擬機(jī)的一項(xiàng)任務(wù)就是負(fù)責(zé)線程的調(diào)度，線程調(diào)度是指按照特定機(jī)制為多個線程分配 CPU 的使用權(quán)。

有兩種調(diào)度模型：分時調(diào)度模型和搶占式調(diào)度模型。

分時調(diào)度模型是指讓所有的線程輪流獲得 cpu 的使用權(quán)，并且平均分配每個線程占用的 CPU 的時間片這個也比較好理解。

Java虛擬機(jī)采用搶占式調(diào)度模型，是指優(yōu)先讓可運(yùn)行池中優(yōu)先級高的線程占用CPU，如果可運(yùn)行池中的線程優(yōu)先級相同，那么就隨機(jī)選擇一個線程，使其占用CPU。處于運(yùn)行狀態(tài)的線程會一直運(yùn)行，直至它不得不放棄 CPU。

線程的調(diào)度策略

線程調(diào)度器選擇優(yōu)先級最高的線程運(yùn)行，但是，如果發(fā)生以下情況，就會終止線程的運(yùn)行：

（1）線程體中調(diào)用了 yield 方法讓出了對 cpu 的占用權(quán)利

（2）線程體中調(diào)用了 sleep 方法使線程進(jìn)入睡眠狀態(tài)

（3）線程由于 IO 操作受到阻塞

（4）另外一個更高優(yōu)先級線程出現(xiàn)

（5）在支持時間片的系統(tǒng)中，該線程的時間片用完

什么是線程調(diào)度器(Thread Scheduler)和時間分片(Time Slicing )？

線程調(diào)度器是一個操作系統(tǒng)服務(wù)，它負(fù)責(zé)為 Runnable 狀態(tài)的線程分配 CPU 時間。一旦我們創(chuàng)建一個線程并啟動它，它的執(zhí)行便依賴于線程調(diào)度器的實(shí)現(xiàn)。

時間分片是指將可用的 CPU 時間分配給可用的 Runnable 線程的過程。分配 CPU 時間可以基于線程優(yōu)先級或者線程等待的時間。

線程調(diào)度并不受到 Java 虛擬機(jī)控制，所以由應(yīng)用程序來控制它是更好的選擇（也就是說不要讓你的程序依賴于線程的優(yōu)先級）。

請說出與線程同步以及線程調(diào)度相關(guān)的方法。

（1） wait()：使一個線程處于等待（阻塞）狀態(tài)，并且釋放所持有的對象的鎖；

（2）sleep()：使一個正在運(yùn)行的線程處于睡眠狀態(tài)，是一個靜態(tài)方法，調(diào)用此方法要處理 InterruptedException 異常；

（3）notify()：喚醒一個處于等待狀態(tài)的線程，當(dāng)然在調(diào)用此方法的時候，并不能確切的喚醒某一個等待狀態(tài)的線程，而是由 JVM 確定喚醒哪個線程，而且與優(yōu)先級無關(guān)；

（4）notityAll()：喚醒所有處于等待狀態(tài)的線程，該方法并不是將對象的鎖給所有線程，而是讓它們競爭，只有獲得鎖的線程才能進(jìn)入就緒狀態(tài)；

sleep() 和 wait() 有什么區(qū)別？

兩者都可以暫停線程的執(zhí)行

類的不同：sleep() 是 Thread線程類的靜態(tài)方法，wait() 是 Object類的方法。
是否釋放鎖：sleep() 不釋放鎖；wait() 釋放鎖。
用途不同：Wait 通常被用于線程間交互/通信，sleep 通常被用于暫停執(zhí)行。
用法不同：wait() 方法被調(diào)用后，線程不會自動蘇醒，需要別的線程調(diào)用同一個對象上的 notify() 或者 notifyAll() 方法。sleep() 方法執(zhí)行完成后，線程會自動蘇醒。或者可以使用wait(long timeout)超時后線程會自動蘇醒。

你是如何調(diào)用 wait() 方法的？使用 if 塊還是循環(huán)？為什么？

處于等待狀態(tài)的線程可能會收到錯誤警報和偽喚醒，如果不在循環(huán)中檢查等待條件，程序就會在沒有滿足結(jié)束條件的情況下退出。

wait() 方法應(yīng)該在循環(huán)調(diào)用，因?yàn)楫?dāng)線程獲取到 CPU 開始執(zhí)行的時候，其他條件可能還沒有滿足，所以在處理前，循環(huán)檢測條件是否滿足會更好。下面是一段標(biāo)準(zhǔn)的使用 wait 和 notify 方法的代碼：

synchronized (monitor) { // 判斷條件謂詞是否得到滿足 while(!locked) { // 等待喚醒 monitor.wait(); } // 處理其他的業(yè)務(wù)邏輯}

為什么線程通信的方法 wait(), notify()和 notifyAll()被定義在 Object 類里？

Java中，任何對象都可以作為鎖，并且 wait()，notify()等方法用于等待對象的鎖或者喚醒線程，在 Java 的線程中并沒有可供任何對象使用的鎖，所以任意對象調(diào)用方法一定定義在Object類中。

wait(), notify()和 notifyAll()這些方法在同步代碼塊中調(diào)用

有的人會說，既然是線程放棄對象鎖，那也可以把wait()定義在Thread類里面啊，新定義的線程繼承于Thread類，也不需要重新定義wait()方法的實(shí)現(xiàn)。然而，這樣做有一個非常大的問題，一個線程完全可以持有很多鎖，你一個線程放棄鎖的時候，到底要放棄哪個鎖？當(dāng)然了，這種設(shè)計(jì)并不是不能實(shí)現(xiàn)，只是管理起來更加復(fù)雜。

綜上所述，wait()、notify()和notifyAll()方法要定義在Object類中。

為什么 wait(), notify()和 notifyAll()必須在同步方法或者同步塊中被調(diào)用？

當(dāng)一個線程需要調(diào)用對象的 wait()方法的時候，這個線程必須擁有該對象的鎖，接著它就會釋放這個對象鎖并進(jìn)入等待狀態(tài)直到其他線程調(diào)用這個對象上的 notify()方法。同樣的，當(dāng)一個線程需要調(diào)用對象的 notify()方法時，它會釋放這個對象的鎖，以便其他在等待的線程就可以得到這個對象鎖。由于所有的這些方法都需要線程持有對象的鎖，這樣就只能通過同步來實(shí)現(xiàn)，所以他們只能在同步方法或者同步塊中被調(diào)用。

Thread 類中的 yield 方法有什么作用？

使當(dāng)前線程從執(zhí)行狀態(tài)（運(yùn)行狀態(tài)）變?yōu)榭蓤?zhí)行態(tài)（就緒狀態(tài)）。

當(dāng)前線程到了就緒狀態(tài)，那么接下來哪個線程會從就緒狀態(tài)變成執(zhí)行狀態(tài)呢？可能是當(dāng)前線程，也可能是其他線程，看系統(tǒng)的分配了。

為什么 Thread 類的 sleep()和 yield ()方法是靜態(tài)的？

Thread 類的 sleep()和 yield()方法將在當(dāng)前正在執(zhí)行的線程上運(yùn)行。所以在其他處于等待狀態(tài)的線程上調(diào)用這些方法是沒有意義的。這就是為什么這些方法是靜態(tài)的。它們可以在當(dāng)前正在執(zhí)行的線程中工作，并避免程序員錯誤的認(rèn)為可以在其他非運(yùn)行線程調(diào)用這些方法。

線程的 sleep()方法和 yield()方法有什么區(qū)別？

（1） sleep()方法給其他線程運(yùn)行機(jī)會時不考慮線程的優(yōu)先級，因此會給低優(yōu)先級的線程以運(yùn)行的機(jī)會；yield()方法只會給相同優(yōu)先級或更高優(yōu)先級的線程以運(yùn)行的機(jī)會；

（2）線程執(zhí)行 sleep()方法后轉(zhuǎn)入阻塞（blocked）狀態(tài)，而執(zhí)行 yield()方法后轉(zhuǎn)入就緒（ready）狀態(tài)；

（3）sleep()方法聲明拋出 InterruptedException，而 yield()方法沒有聲明任何異常；

（4）sleep()方法比 yield()方法（跟操作系統(tǒng) CPU 調(diào)度相關(guān)）具有更好的可移植性，通常不建議使用yield()方法來控制并發(fā)線程的執(zhí)行。

如何停止一個正在運(yùn)行的線程？

在java中有以下3種方法可以終止正在運(yùn)行的線程：

使用退出標(biāo)志，使線程正常退出，也就是當(dāng)run方法完成后線程終止。

使用stop方法強(qiáng)行終止，但是不推薦這個方法，因?yàn)閟top和suspend及resume一樣都是過期作廢的方法。

使用interrupt方法中斷線程。

Java 中 interrupted 和 isInterrupted 方法的區(qū)別？

interrupt：用于中斷線程。調(diào)用該方法的線程的狀態(tài)為將被置為”中斷”狀態(tài)。

注意：線程中斷僅僅是置線程的中斷狀態(tài)位，不會停止線程。需要用戶自己去監(jiān)視線程的狀態(tài)為并做處理。支持線程中斷的方法（也就是線程中斷后會拋出interruptedException 的方法）就是在監(jiān)視線程的中斷狀態(tài)，一旦線程的中斷狀態(tài)被置為“中斷狀態(tài)”，就會拋出中斷異常。

interrupted：是靜態(tài)方法，查看當(dāng)前中斷信號是true還是false并且清除中斷信號。如果一個線程被中斷了，第一次調(diào)用 interrupted 則返回 true，第二次和后面的就返回 false 了。

isInterrupted：查看當(dāng)前中斷信號是true還是false

什么是阻塞式方法？

阻塞式方法是指程序會一直等待該方法完成期間不做其他事情，ServerSocket 的accept()方法就是一直等待客戶端連接。這里的阻塞是指調(diào)用結(jié)果返回之前，當(dāng)前線程會被掛起，直到得到結(jié)果之后才會返回。此外，還有異步和非阻塞式方法在任務(wù)完成前就返回。

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

首先，wait()、notify() 方法是針對對象的，調(diào)用任意對象的 wait()方法都將導(dǎo)致線程阻塞，阻塞的同時也將釋放該對象的鎖，相應(yīng)地，調(diào)用任意對象的 notify()方法則將隨機(jī)解除該對象阻塞的線程，但它需要重新獲取該對象的鎖，直到獲取成功才能往下執(zhí)行；

其次，wait、notify 方法必須在 synchronized 塊或方法中被調(diào)用，并且要保證同步塊或方法的鎖對象與調(diào)用 wait、notify 方法的對象是同一個，如此一來在調(diào)用 wait 之前當(dāng)前線程就已經(jīng)成功獲取某對象的鎖，執(zhí)行 wait 阻塞后當(dāng)前線程就將之前獲取的對象鎖釋放。

notify() 和 notifyAll() 有什么區(qū)別？

如果線程調(diào)用了對象的 wait()方法，那么線程便會處于該對象的等待池中，等待池中的線程不會去競爭該對象的鎖。

notifyAll() 會喚醒所有的線程，notify() 只會喚醒一個線程。

notifyAll() 調(diào)用后，會將全部線程由等待池移到鎖池，然后參與鎖的競爭，競爭成功則繼續(xù)執(zhí)行，如果不成功則留在鎖池等待鎖被釋放后再次參與競爭。而 notify()只會喚醒一個線程，具體喚醒哪一個線程由虛擬機(jī)控制。

如何在兩個線程間共享數(shù)據(jù)？

在兩個線程間共享變量即可實(shí)現(xiàn)共享。

一般來說，共享變量要求變量本身是線程安全的，然后在線程內(nèi)使用的時候，如果有對共享變量的復(fù)合操作，那么也得保證復(fù)合操作的線程安全性。

Java 如何實(shí)現(xiàn)多線程之間的通訊和協(xié)作？

可以通過中斷和共享變量的方式實(shí)現(xiàn)線程間的通訊和協(xié)作

比如說最經(jīng)典的生產(chǎn)者-消費(fèi)者模型：當(dāng)隊(duì)列滿時，生產(chǎn)者需要等待隊(duì)列有空間才能繼續(xù)往里面放入商品，而在等待的期間內(nèi)，生產(chǎn)者必須釋放對臨界資源（即隊(duì)列）的占用權(quán)。因?yàn)樯a(chǎn)者如果不釋放對臨界資源的占用權(quán)，那么消費(fèi)者就無法消費(fèi)隊(duì)列中的商品，就不會讓隊(duì)列有空間，那么生產(chǎn)者就會一直無限等待下去。因此，一般情況下，當(dāng)隊(duì)列滿時，會讓生產(chǎn)者交出對臨界資源的占用權(quán)，并進(jìn)入掛起狀態(tài)。然后等待消費(fèi)者消費(fèi)了商品，然后消費(fèi)者通知生產(chǎn)者隊(duì)列有空間了。同樣地，當(dāng)隊(duì)列空時，消費(fèi)者也必須等待，等待生產(chǎn)者通知它隊(duì)列中有商品了。這種互相通信的過程就是線程間的協(xié)作。

Java中線程通信協(xié)作的最常見的兩種方式：

一.syncrhoized加鎖的線程的Object類的wait()/notify()/notifyAll()

二.ReentrantLock類加鎖的線程的Condition類的await()/signal()/signalAll()

線程間直接的數(shù)據(jù)交換：

三.通過管道進(jìn)行線程間通信：1）字節(jié)流；2）字符流

同步方法和同步塊，哪個是更好的選擇？

同步塊是更好的選擇，因?yàn)樗粫i住整個對象（當(dāng)然你也可以讓它鎖住整個對象）。同步方法會鎖住整個對象，哪怕這個類中有多個不相關(guān)聯(lián)的同步塊，這通常會導(dǎo)致他們停止執(zhí)行并需要等待獲得這個對象上的鎖。

同步塊更要符合開放調(diào)用的原則，只在需要鎖住的代碼塊鎖住相應(yīng)的對象，這樣從側(cè)面來說也可以避免死鎖。

請知道一條原則：同步的范圍越小越好。

什么是線程同步和線程互斥，有哪幾種實(shí)現(xiàn)方式？

當(dāng)一個線程對共享的數(shù)據(jù)進(jìn)行操作時，應(yīng)使之成為一個”原子操作“，即在沒有完成相關(guān)操作之前，不允許其他線程打斷它，否則，就會破壞數(shù)據(jù)的完整性，必然會得到錯誤的處理結(jié)果，這就是線程的同步。

在多線程應(yīng)用中，考慮不同線程之間的數(shù)據(jù)同步和防止死鎖。當(dāng)兩個或多個線程之間同時等待對方釋放資源的時候就會形成線程之間的死鎖。為了防止死鎖的發(fā)生，需要通過同步來實(shí)現(xiàn)線程安全。

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

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

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

實(shí)現(xiàn)線程同步的方法

同步代碼方法：sychronized 關(guān)鍵字修飾的方法

?
同步代碼塊：sychronized 關(guān)鍵字修飾的代碼塊

?
使用特殊變量域volatile實(shí)現(xiàn)線程同步：volatile關(guān)鍵字為域變量的訪問提供了一種免鎖機(jī)制

?
使用重入鎖實(shí)現(xiàn)線程同步：reentrantlock類是可沖入、互斥、實(shí)現(xiàn)了lock接口的鎖他與sychronized方法具有相同的基本行為和語義

在監(jiān)視器(Monitor)內(nèi)部，是如何做線程同步的？程序應(yīng)該做哪種級別的同步？

在 java 虛擬機(jī)中，每個對象( Object 和 class )通過某種邏輯關(guān)聯(lián)監(jiān)視器,每個監(jiān)視器和一個對象引用相關(guān)聯(lián)，為了實(shí)現(xiàn)監(jiān)視器的互斥功能，每個對象都關(guān)聯(lián)著一把鎖。

一旦方法或者代碼塊被 synchronized 修飾，那么這個部分就放入了監(jiān)視器的監(jiān)視區(qū)域，確保一次只能有一個線程執(zhí)行該部分的代碼，線程在獲取鎖之前不允許執(zhí)行該部分的代碼

另外 java 還提供了顯式監(jiān)視器( Lock )和隱式監(jiān)視器( synchronized )兩種鎖方案

如果你提交任務(wù)時，線程池隊(duì)列已滿，這時會發(fā)生什么

這里區(qū)分一下：

（1）如果使用的是無界隊(duì)列 LinkedBlockingQueue，也就是無界隊(duì)列的話，沒關(guān)系，繼續(xù)添加任務(wù)到阻塞隊(duì)列中等待執(zhí)行，因?yàn)?LinkedBlockingQueue 可以近乎認(rèn)為是一個無窮大的隊(duì)列，可以無限存放任務(wù)

（2）如果使用的是有界隊(duì)列比如 ArrayBlockingQueue，任務(wù)首先會被添加到ArrayBlockingQueue 中，ArrayBlockingQueue 滿了，會根據(jù)maximumPoolSize 的值增加線程數(shù)量，如果增加了線程數(shù)量還是處理不過來，ArrayBlockingQueue 繼續(xù)滿，那么則會使用拒絕策略RejectedExecutionHandler 處理滿了的任務(wù)，默認(rèn)是 AbortPolicy

什么叫線程安全？servlet 是線程安全嗎?

線程安全是編程中的術(shù)語，指某個方法在多線程環(huán)境中被調(diào)用時，能夠正確地處理多個線程之間的共享變量，使程序功能正確完成。

Servlet 不是線程安全的，servlet 是單實(shí)例多線程的，當(dāng)多個線程同時訪問同一個方法，是不能保證共享變量的線程安全性的。

Struts2 的 action 是多實(shí)例多線程的，是線程安全的，每個請求過來都會 new 一個新的 action 分配給這個請求，請求完成后銷毀。

SpringMVC 的 Controller 是線程安全的嗎？不是的，和 Servlet 類似的處理流程。

Struts2 好處是不用考慮線程安全問題；Servlet 和 SpringMVC 需要考慮線程安全問題，但是性能可以提升不用處理太多的 gc，可以使用 ThreadLocal 來處理多線程的問題。

在 Java 程序中怎么保證多線程的運(yùn)行安全？

方法一：使用安全類，比如 java.util.concurrent 下的類，使用原子類AtomicInteger
方法二：使用自動鎖 synchronized。
方法三：使用手動鎖 Lock。

手動鎖 Java 示例代碼如下：

Lock lock = new ReentrantLock();lock. lock();try { System. out. println("獲得鎖");} catch (Exception e) { // TODO: handle exception} finally { System. out. println("釋放鎖"); lock. unlock();}

你對線程優(yōu)先級的理解是什么？

每一個線程都是有優(yōu)先級的，一般來說，高優(yōu)先級的線程在運(yùn)行時會具有優(yōu)先權(quán)，但這依賴于線程調(diào)度的實(shí)現(xiàn)，這個實(shí)現(xiàn)是和操作系統(tǒng)相關(guān)的(OS dependent)。我們可以定義線程的優(yōu)先級，但是這并不能保證高優(yōu)先級的線程會在低優(yōu)先級的線程前執(zhí)行。線程優(yōu)先級是一個 int 變量(從 1-10)，1 代表最低優(yōu)先級，10 代表最高優(yōu)先級。

Java 的線程優(yōu)先級調(diào)度會委托給操作系統(tǒng)去處理，所以與具體的操作系統(tǒng)優(yōu)先級有關(guān)，如非特別需要，一般無需設(shè)置線程優(yōu)先級。

線程類的構(gòu)造方法、靜態(tài)塊是被哪個線程調(diào)用的

這是一個非常刁鉆和狡猾的問題。請記住：線程類的構(gòu)造方法、靜態(tài)塊是被 new這個線程類所在的線程所調(diào)用的，而 run 方法里面的代碼才是被線程自身所調(diào)用的。

如果說上面的說法讓你感到困惑，那么我舉個例子，假設(shè) Thread2 中 new 了Thread1，main 函數(shù)中 new 了 Thread2，那么：

（1）Thread2 的構(gòu)造方法、靜態(tài)塊是 main 線程調(diào)用的，Thread2 的 run()方法是Thread2 自己調(diào)用的

（2）Thread1 的構(gòu)造方法、靜態(tài)塊是 Thread2 調(diào)用的，Thread1 的 run()方法是Thread1 自己調(diào)用的

Java 中怎么獲取一份線程 dump 文件？你如何在 Java 中獲取線程堆棧？

Dump文件是進(jìn)程的內(nèi)存鏡像。可以把程序的執(zhí)行狀態(tài)通過調(diào)試器保存到dump文件中。

在 Linux 下，你可以通過命令 kill -3 PID （Java 進(jìn)程的進(jìn)程 ID）來獲取 Java應(yīng)用的 dump 文件。

在 Windows 下，你可以按下 Ctrl + Break 來獲取。這樣 JVM 就會將線程的 dump 文件打印到標(biāo)準(zhǔn)輸出或錯誤文件中，它可能打印在控制臺或者日志文件中，具體位置依賴應(yīng)用的配置。

一個線程運(yùn)行時發(fā)生異常會怎樣？

如果異常沒有被捕獲該線程將會停止執(zhí)行。Thread.UncaughtExceptionHandler是用于處理未捕獲異常造成線程突然中斷情況的一個內(nèi)嵌接口。當(dāng)一個未捕獲異常將造成線程中斷的時候，JVM 會使用 Thread.getUncaughtExceptionHandler()來查詢線程的 UncaughtExceptionHandler 并將線程和異常作為參數(shù)傳遞給 handler 的 uncaughtException()方法進(jìn)行處理。

Java 線程數(shù)過多會造成什么異常？

線程的生命周期開銷非常高

?
消耗過多的 CPU

?
資源如果可運(yùn)行的線程數(shù)量多于可用處理器的數(shù)量，那么有線程將會被閑置。大量空閑的線程會占用許多內(nèi)存，給垃圾回收器帶來壓力，而且大量的線程在競爭 CPU資源時還將產(chǎn)生其他性能的開銷。

?
降低穩(wěn)定性JVM

?
在可創(chuàng)建線程的數(shù)量上存在一個限制，這個限制值將隨著平臺的不同而不同，并且承受著多個因素制約，包括 JVM 的啟動參數(shù)、Thread 構(gòu)造函數(shù)中請求棧的大小，以及底層操作系統(tǒng)對線程的限制等。如果破壞了這些限制，那么可能拋出OutOfMemoryError 異常。

并發(fā)理論

Java內(nèi)存模型

Java中垃圾回收有什么目的？什么時候進(jìn)行垃圾回收？

垃圾回收是在內(nèi)存中存在沒有引用的對象或超過作用域的對象時進(jìn)行的。

垃圾回收的目的是識別并且丟棄應(yīng)用不再使用的對象來釋放和重用資源。

如果對象的引用被置為null，垃圾收集器是否會立即釋放對象占用的內(nèi)存？

不會，在下一個垃圾回調(diào)周期中，這個對象將是被可回收的。

也就是說并不會立即被垃圾收集器立刻回收，而是在下一次垃圾回收時才會釋放其占用的內(nèi)存。

finalize()方法什么時候被調(diào)用？析構(gòu)函數(shù)(finalization)的目的是什么？

1）垃圾回收器（garbage colector）決定回收某對象時，就會運(yùn)行該對象的finalize()方法；

finalize是Object類的一個方法，該方法在Object類中的聲明protected void finalize() throws Throwable { }

在垃圾回收器執(zhí)行時會調(diào)用被回收對象的finalize()方法，可以覆蓋此方法來實(shí)現(xiàn)對其資源的回收。注意：一旦垃圾回收器準(zhǔn)備釋放對象占用的內(nèi)存，將首先調(diào)用該對象的finalize()方法，并且下一次垃圾回收動作發(fā)生時，才真正回收對象占用的內(nèi)存空間

2）GC本來就是內(nèi)存回收了，應(yīng)用還需要在finalization做什么呢？答案是大部分時候，什么都不用做(也就是不需要重載)。只有在某些很特殊的情況下，比如你調(diào)用了一些native的方法(一般是C寫的)，可以要在finaliztion里去調(diào)用C的釋放函數(shù)。

重排序與數(shù)據(jù)依賴性

為什么代碼會重排序？

在執(zhí)行程序時，為了提供性能，處理器和編譯器常常會對指令進(jìn)行重排序，但是不能隨意重排序，不是你想怎么排序就怎么排序，它需要滿足以下兩個條件：

在單線程環(huán)境下不能改變程序運(yùn)行的結(jié)果；
存在數(shù)據(jù)依賴關(guān)系的不允許重排序

需要注意的是：重排序不會影響單線程環(huán)境的執(zhí)行結(jié)果，但是會破壞多線程的執(zhí)行語義。

as-if-serial規(guī)則和happens-before規(guī)則的區(qū)別

as-if-serial語義保證單線程內(nèi)程序的執(zhí)行結(jié)果不被改變，happens-before關(guān)系保證正確同步的多線程程序的執(zhí)行結(jié)果不被改變。

?
as-if-serial語義給編寫單線程程序的程序員創(chuàng)造了一個幻境：單線程程序是按程序的順序來執(zhí)行的。happens-before關(guān)系給編寫正確同步的多線程程序的程序員創(chuàng)造了一個幻境：正確同步的多線程程序是按happens-before指定的順序來執(zhí)行的。

?
as-if-serial語義和happens-before這么做的目的，都是為了在不改變程序執(zhí)行結(jié)果的前提下，盡可能地提高程序執(zhí)行的并行度。

并發(fā)關(guān)鍵字

synchronized

synchronized 的作用？

在 Java 中，synchronized 關(guān)鍵字是用來控制線程同步的，就是在多線程的環(huán)境下，控制 synchronized 代碼段不被多個線程同時執(zhí)行。synchronized 可以修飾類、方法、變量。

另外，在 Java 早期版本中，synchronized屬于重量級鎖，效率低下，因?yàn)楸O(jiān)視器鎖（monitor）是依賴于底層的操作系統(tǒng)的 Mutex Lock 來實(shí)現(xiàn)的，Java 的線程是映射到操作系統(tǒng)的原生線程之上的。如果要掛起或者喚醒一個線程，都需要操作系統(tǒng)幫忙完成，而操作系統(tǒng)實(shí)現(xiàn)線程之間的切換時需要從用戶態(tài)轉(zhuǎn)換到內(nèi)核態(tài)，這個狀態(tài)之間的轉(zhuǎn)換需要相對比較長的時間，時間成本相對較高，這也是為什么早期的 synchronized 效率低的原因。慶幸的是在 Java 6 之后 Java 官方對從 JVM 層面對synchronized 較大優(yōu)化，所以現(xiàn)在的 synchronized 鎖效率也優(yōu)化得很不錯了。JDK1.6對鎖的實(shí)現(xiàn)引入了大量的優(yōu)化，如自旋鎖、適應(yīng)性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術(shù)來減少鎖操作的開銷。

說說自己是怎么使用 synchronized 關(guān)鍵字，在項(xiàng)目中用到了嗎

synchronized關(guān)鍵字最主要的三種使用方式：

修飾實(shí)例方法: 作用于當(dāng)前對象實(shí)例加鎖，進(jìn)入同步代碼前要獲得當(dāng)前對象實(shí)例的鎖
修飾靜態(tài)方法: 也就是給當(dāng)前類加鎖，會作用于類的所有對象實(shí)例，因?yàn)殪o態(tài)成員不屬于任何一個實(shí)例對象，是類成員（ static 表明這是該類的一個靜態(tài)資源，不管new了多少個對象，只有一份）。所以如果一個線程A調(diào)用一個實(shí)例對象的非靜態(tài) synchronized 方法，而線程B需要調(diào)用這個實(shí)例對象所屬類的靜態(tài) synchronized 方法，是允許的，不會發(fā)生互斥現(xiàn)象，因?yàn)樵L問靜態(tài) synchronized 方法占用的鎖是當(dāng)前類的鎖，而訪問非靜態(tài) synchronized 方法占用的鎖是當(dāng)前實(shí)例對象鎖。
修飾代碼塊: 指定加鎖對象，對給定對象加鎖，進(jìn)入同步代碼庫前要獲得給定對象的鎖。

總結(jié)：synchronized 關(guān)鍵字加到 static 靜態(tài)方法和 synchronized(class)代碼塊上都是是給 Class 類上鎖。synchronized 關(guān)鍵字加到實(shí)例方法上是給對象實(shí)例上鎖。盡量不要使用 synchronized(String a) 因?yàn)镴VM中，字符串常量池具有緩存功能！

下面我以一個常見的面試題為例講解一下 synchronized 關(guān)鍵字的具體使用。

面試中面試官經(jīng)常會說：“單例模式了解嗎？來給我手寫一下！給我解釋一下雙重檢驗(yàn)鎖方式實(shí)現(xiàn)單例模式的原理唄！”

雙重校驗(yàn)鎖實(shí)現(xiàn)對象單例（線程安全）

public class Singleton { private volatile static Singleton uniqueInstance; private Singleton() { } public static Singleton getUniqueInstance() { //先判斷對象是否已經(jīng)實(shí)例過，沒有實(shí)例化過才進(jìn)入加鎖代碼 if (uniqueInstance == null) { //類對象加鎖 synchronized (Singleton.class) { if (uniqueInstance == null) { uniqueInstance = new Singleton(); } } } return uniqueInstance; }}

另外，需要注意 uniqueInstance 采用 volatile 關(guān)鍵字修飾也是很有必要。

uniqueInstance 采用 volatile 關(guān)鍵字修飾也是很有必要的， uniqueInstance = new Singleton(); 這段代碼其實(shí)是分為三步執(zhí)行：

為 uniqueInstance 分配內(nèi)存空間

初始化 uniqueInstance

將 uniqueInstance 指向分配的內(nèi)存地址

但是由于 JVM 具有指令重排的特性，執(zhí)行順序有可能變成 1->3->2。指令重排在單線程環(huán)境下不會出現(xiàn)問題，但是在多線程環(huán)境下會導(dǎo)致一個線程獲得還沒有初始化的實(shí)例。例如，線程 T1 執(zhí)行了 1 和 3，此時 T2 調(diào)用 getUniqueInstance() 后發(fā)現(xiàn) uniqueInstance 不為空，因此返回 uniqueInstance，但此時 uniqueInstance 還未被初始化。

使用 volatile 可以禁止 JVM 的指令重排，保證在多線程環(huán)境下也能正常運(yùn)行。

說一下 synchronized 底層實(shí)現(xiàn)原理？

synchronized是Java中的一個關(guān)鍵字，在使用的過程中并沒有看到顯示的加鎖和解鎖過程。因此有必要通過javap命令，查看相應(yīng)的字節(jié)碼文件。

synchronized 同步語句塊的情況

public class SynchronizedDemo { public void method() { synchronized (this) { System.out.println("synchronized 代碼塊"); } }}

通過JDK 反匯編指令 javap -c -v SynchronizedDemo

可以看出在執(zhí)行同步代碼塊之前之后都有一個monitor字樣，其中前面的是monitorenter，后面的是離開monitorexit，不難想象一個線程也執(zhí)行同步代碼塊，首先要獲取鎖，而獲取鎖的過程就是monitorenter ，在執(zhí)行完代碼塊之后，要釋放鎖，釋放鎖就是執(zhí)行monitorexit指令。

為什么會有兩個monitorexit呢？

這個主要是防止在同步代碼塊中線程因異常退出，而鎖沒有得到釋放，這必然會造成死鎖（等待的線程永遠(yuǎn)獲取不到鎖）。因此最后一個monitorexit是保證在異常情況下，鎖也可以得到釋放，避免死鎖。

僅有ACC_SYNCHRONIZED這么一個標(biāo)志，該標(biāo)記表明線程進(jìn)入該方法時，需要monitorenter，退出該方法時需要monitorexit。

synchronized可重入的原理

重入鎖是指一個線程獲取到該鎖之后，該線程可以繼續(xù)獲得該鎖。底層原理維護(hù)一個計(jì)數(shù)器，當(dāng)線程獲取該鎖時，計(jì)數(shù)器加一，再次獲得該鎖時繼續(xù)加一，釋放鎖時，計(jì)數(shù)器減一，當(dāng)計(jì)數(shù)器值為0時，表明該鎖未被任何線程所持有，其它線程可以競爭獲取鎖。

什么是自旋

很多 synchronized 里面的代碼只是一些很簡單的代碼，執(zhí)行時間非常快，此時等待的線程都加鎖可能是一種不太值得的操作，因?yàn)榫€程阻塞涉及到用戶態(tài)和內(nèi)核態(tài)切換的問題。既然 synchronized 里面的代碼執(zhí)行得非常快，不妨讓等待鎖的線程不要被阻塞，而是在 synchronized 的邊界做忙循環(huán)，這就是自旋。如果做了多次循環(huán)發(fā)現(xiàn)還沒有獲得鎖，再阻塞，這樣可能是一種更好的策略。

多線程中 synchronized 鎖升級的原理是什么？

synchronized 鎖升級原理：在鎖對象的對象頭里面有一個 threadid 字段，在第一次訪問的時候 threadid 為空，jvm 讓其持有偏向鎖，并將 threadid 設(shè)置為其線程 id，再次進(jìn)入的時候會先判斷 threadid 是否與其線程 id 一致，如果一致則可以直接使用此對象，如果不一致，則升級偏向鎖為輕量級鎖，通過自旋循環(huán)一定次數(shù)來獲取鎖，執(zhí)行一定次數(shù)之后，如果還沒有正常獲取到要使用的對象，此時就會把鎖從輕量級升級為重量級鎖，此過程就構(gòu)成了 synchronized 鎖的升級。

鎖的升級的目的：鎖升級是為了減低了鎖帶來的性能消耗。在 Java 6 之后優(yōu)化 synchronized 的實(shí)現(xiàn)方式，使用了偏向鎖升級為輕量級鎖再升級到重量級鎖的方式，從而減低了鎖帶來的性能消耗。

線程 B 怎么知道線程 A 修改了變量

（1）volatile 修飾變量

（2）synchronized 修飾修改變量的方法

（3）wait/notify

（4）while 輪詢

當(dāng)一個線程進(jìn)入一個對象的 synchronized 方法 A 之后，其它線程是否可進(jìn)入此對象的 synchronized 方法 B？

不能。其它線程只能訪問該對象的非同步方法，同步方法則不能進(jìn)入。因?yàn)榉庆o態(tài)方法上的 synchronized 修飾符要求執(zhí)行方法時要獲得對象的鎖，如果已經(jīng)進(jìn)入A 方法說明對象鎖已經(jīng)被取走，那么試圖進(jìn)入 B 方法的線程就只能在等鎖池（注意不是等待池哦）中等待對象的鎖。

synchronized、volatile、CAS 比較

（1）synchronized 是悲觀鎖，屬于搶占式，會引起其他線程阻塞。

（2）volatile 提供多線程共享變量可見性和禁止指令重排序優(yōu)化。

（3）CAS 是基于沖突檢測的樂觀鎖（非阻塞）

synchronized 和 Lock 有什么區(qū)別？

首先synchronized是Java內(nèi)置關(guān)鍵字，在JVM層面，Lock是個Java類；
synchronized 可以給類、方法、代碼塊加鎖；而 lock 只能給代碼塊加鎖。
synchronized 不需要手動獲取鎖和釋放鎖，使用簡單，發(fā)生異常會自動釋放鎖，不會造成死鎖；而 lock 需要自己加鎖和釋放鎖，如果使用不當(dāng)沒有 unLock()去釋放鎖就會造成死鎖。
通過 Lock 可以知道有沒有成功獲取鎖，而 synchronized 卻無法辦到。

synchronized 和 ReentrantLock 區(qū)別是什么？

synchronized 是和 if、else、for、while 一樣的關(guān)鍵字，ReentrantLock 是類，這是二者的本質(zhì)區(qū)別。既然 ReentrantLock 是類，那么它就提供了比synchronized 更多更靈活的特性，可以被繼承、可以有方法、可以有各種各樣的類變量

synchronized 早期的實(shí)現(xiàn)比較低效，對比 ReentrantLock，大多數(shù)場景性能都相差較大，但是在 Java 6 中對 synchronized 進(jìn)行了非常多的改進(jìn)。

相同點(diǎn)：兩者都是可重入鎖

兩者都是可重入鎖。“可重入鎖”概念是：自己可以再次獲取自己的內(nèi)部鎖。比如一個線程獲得了某個對象的鎖，此時這個對象鎖還沒有釋放，當(dāng)其再次想要獲取這個對象的鎖的時候還是可以獲取的，如果不可鎖重入的話，就會造成死鎖。同一個線程每次獲取鎖，鎖的計(jì)數(shù)器都自增1，所以要等到鎖的計(jì)數(shù)器下降為0時才能釋放鎖。

主要區(qū)別如下：

ReentrantLock 使用起來比較靈活，但是必須有釋放鎖的配合動作；
ReentrantLock 必須手動獲取與釋放鎖，而 synchronized 不需要手動釋放和開啟鎖；
ReentrantLock 只適用于代碼塊鎖，而 synchronized 可以修飾類、方法、變量等。
二者的鎖機(jī)制其實(shí)也是不一樣的。ReentrantLock 底層調(diào)用的是 Unsafe 的park 方法加鎖，synchronized 操作的應(yīng)該是對象頭中 mark word

Java中每一個對象都可以作為鎖，這是synchronized實(shí)現(xiàn)同步的基礎(chǔ)：

普通同步方法，鎖是當(dāng)前實(shí)例對象
靜態(tài)同步方法，鎖是當(dāng)前類的class對象
同步方法塊，鎖是括號里面的對象

volatile

volatile 關(guān)鍵字的作用

對于可見性，Java 提供了 volatile 關(guān)鍵字來保證可見性和禁止指令重排。volatile 提供 happens-before 的保證，確保一個線程的修改能對其他線程是可見的。當(dāng)一個共享變量被 volatile 修飾時，它會保證修改的值會立即被更新到主存，當(dāng)有其他線程需要讀取時，它會去內(nèi)存中讀取新值。

從實(shí)踐角度而言，volatile 的一個重要作用就是和 CAS 結(jié)合，保證了原子性，詳細(xì)的可以參見 java.util.concurrent.atomic 包下的類，比如 AtomicInteger。

volatile 常用于多線程環(huán)境下的單次操作(單次讀或者單次寫)。

Java 中能創(chuàng)建 volatile 數(shù)組嗎？

能，Java 中可以創(chuàng)建 volatile 類型數(shù)組，不過只是一個指向數(shù)組的引用，而不是整個數(shù)組。意思是，如果改變引用指向的數(shù)組，將會受到 volatile 的保護(hù)，但是如果多個線程同時改變數(shù)組的元素，volatile 標(biāo)示符就不能起到之前的保護(hù)作用了。

volatile 變量和 atomic 變量有什么不同？

volatile 變量可以確保先行關(guān)系，即寫操作會發(fā)生在后續(xù)的讀操作之前, 但它并不能保證原子性。例如用 volatile 修飾 count 變量，那么 count++ 操作就不是原子性的。

而 AtomicInteger 類提供的 atomic 方法可以讓這種操作具有原子性如getAndIncrement()方法會原子性的進(jìn)行增量操作把當(dāng)前值加一，其它數(shù)據(jù)類型和引用變量也可以進(jìn)行相似操作。

volatile 能使得一個非原子操作變成原子操作嗎？

關(guān)鍵字volatile的主要作用是使變量在多個線程間可見，但無法保證原子性，對于多個線程訪問同一個實(shí)例變量需要加鎖進(jìn)行同步。

雖然volatile只能保證可見性不能保證原子性，但用volatile修飾long和double可以保證其操作原子性。

所以從Oracle Java Spec里面可以看到：

對于64位的long和double，如果沒有被volatile修飾，那么對其操作可以不是原子的。在操作的時候，可以分成兩步，每次對32位操作。
如果使用volatile修飾long和double，那么其讀寫都是原子操作
對于64位的引用地址的讀寫，都是原子操作
在實(shí)現(xiàn)JVM時，可以自由選擇是否把讀寫long和double作為原子操作
推薦JVM實(shí)現(xiàn)為原子操作

volatile 修飾符的有過什么實(shí)踐？

單例模式

是否 Lazy 初始化：是

是否多線程安全：是

實(shí)現(xiàn)難度：較復(fù)雜

描述：對于Double-Check這種可能出現(xiàn)的問題（當(dāng)然這種概率已經(jīng)非常小了，但畢竟還是有的嘛~），解決方案是：只需要給instance的聲明加上volatile關(guān)鍵字即可volatile關(guān)鍵字的一個作用是禁止指令重排，把instance聲明為volatile之后，對它的寫操作就會有一個內(nèi)存屏障（什么是內(nèi)存屏障？），這樣，在它的賦值完成之前，就不用會調(diào)用讀操作。注意：volatile阻止的不是singleton = newSingleton()這句話內(nèi)部[1-2-3]的指令重排，而是保證了在一個寫操作（[1-2-3]）完成之前，不會調(diào)用讀操作（if (instance == null)）。

public class Singleton7 { private static volatile Singleton7 instance = null; private Singleton7() {} public static Singleton7 getInstance() { if (instance == null) { synchronized (Singleton7.class) { if (instance == null) { instance = new Singleton7(); } } } return instance; } }

synchronized 和 volatile 的區(qū)別是什么？

synchronized 表示只有一個線程可以獲取作用對象的鎖，執(zhí)行代碼，阻塞其他線程。

volatile 表示變量在 CPU 的寄存器中是不確定的，必須從主存中讀取。保證多線程環(huán)境下變量的可見性；禁止指令重排序。

區(qū)別

volatile 是變量修飾符；synchronized 可以修飾類、方法、變量。

?
volatile 僅能實(shí)現(xiàn)變量的修改可見性，不能保證原子性；而 synchronized 則可以保證變量的修改可見性和原子性。

?
volatile 不會造成線程的阻塞；synchronized 可能會造成線程的阻塞。
?
volatile標(biāo)記的變量不會被編譯器優(yōu)化；synchronized標(biāo)記的變量可以被編譯器優(yōu)化。

?
volatile關(guān)鍵字是線程同步的輕量級實(shí)現(xiàn)，所以volatile性能肯定比synchronized關(guān)鍵字要好。但是volatile關(guān)鍵字只能用于變量而synchronized關(guān)鍵字可以修飾方法以及代碼塊。synchronized關(guān)鍵字在JavaSE1.6之后進(jìn)行了主要包括為了減少獲得鎖和釋放鎖帶來的性能消耗而引入的偏向鎖和輕量級鎖以及其它各種優(yōu)化之后執(zhí)行效率有了顯著提升，實(shí)際開發(fā)中使用 synchronized 關(guān)鍵字的場景還是更多一些。

final

什么是不可變對象，它對寫并發(fā)應(yīng)用有什么幫助？

不可變對象(Immutable Objects)即對象一旦被創(chuàng)建它的狀態(tài)（對象的數(shù)據(jù)，也即對象屬性值）就不能改變，反之即為可變對象(Mutable Objects)。

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

只有滿足如下狀態(tài)，一個對象才是不可變的；

它的狀態(tài)不能在創(chuàng)建后再被修改；
所有域都是 final 類型；并且，它被正確創(chuàng)建（創(chuàng)建期間沒有發(fā)生 this 引用的逸出）。

不可變對象保證了對象的內(nèi)存可見性，對不可變對象的讀取不需要進(jìn)行額外的同步手段，提升了代碼執(zhí)行效率。

Lock體系

Lock簡介與初識AQS

Java Concurrency API 中的 Lock 接口(Lock interface)是什么？對比同步它有什么優(yōu)勢？

Lock 接口比同步方法和同步塊提供了更具擴(kuò)展性的鎖操作。他們允許更靈活的結(jié)構(gòu)，可以具有完全不同的性質(zhì)，并且可以支持多個相關(guān)類的條件對象。

它的優(yōu)勢有：

（1）可以使鎖更公平

（2）可以使線程在等待鎖的時候響應(yīng)中斷

（3）可以讓線程嘗試獲取鎖，并在無法獲取鎖的時候立即返回或者等待一段時間

（4）可以在不同的范圍，以不同的順序獲取和釋放鎖

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

樂觀鎖和悲觀鎖的理解及如何實(shí)現(xiàn)，有哪些實(shí)現(xiàn)方式？

悲觀鎖：總是假設(shè)最壞的情況，每次去拿數(shù)據(jù)的時候都認(rèn)為別人會修改，所以每次在拿數(shù)據(jù)的時候都會上鎖，這樣別人想拿這個數(shù)據(jù)就會阻塞直到它拿到鎖。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫里邊就用到了很多這種鎖機(jī)制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。再比如 Java 里面的同步原語 synchronized 關(guān)鍵字的實(shí)現(xiàn)也是悲觀鎖。

樂觀鎖：顧名思義，就是很樂觀，每次去拿數(shù)據(jù)的時候都認(rèn)為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數(shù)據(jù)，可以使用版本號等機(jī)制。樂觀鎖適用于多讀的應(yīng)用類型，這樣可以提高吞吐量，像數(shù)據(jù)庫提供的類似于 write_condition 機(jī)制，其實(shí)都是提供的樂觀鎖。在 Java中 java.util.concurrent.atomic 包下面的原子變量類就是使用了樂觀鎖的一種實(shí)現(xiàn)方式 CAS 實(shí)現(xiàn)的。

樂觀鎖的實(shí)現(xiàn)方式：

1、使用版本標(biāo)識來確定讀到的數(shù)據(jù)與提交時的數(shù)據(jù)是否一致。提交后修改版本標(biāo)識，不一致時可以采取丟棄和再次嘗試的策略。

2、java 中的 Compare and Swap 即 CAS ，當(dāng)多個線程嘗試使用 CAS 同時更新同一個變量時，只有其中一個線程能更新變量的值，而其它線程都失敗，失敗的線程并不會被掛起，而是被告知這次競爭中失敗，并可以再次嘗試。CAS 操作中包含三個操作數(shù) —— 需要讀寫的內(nèi)存位置（V）、進(jìn)行比較的預(yù)期原值（A）和擬寫入的新值(B)。如果內(nèi)存位置 V 的值與預(yù)期原值 A 相匹配，那么處理器會自動將該位置值更新為新值 B。否則處理器不做任何操作。

什么是 CAS

CAS 是 compare and swap 的縮寫，即我們所說的比較交換。

cas 是一種基于鎖的操作，而且是樂觀鎖。在 java 中鎖分為樂觀鎖和悲觀鎖。悲觀鎖是將資源鎖住，等一個之前獲得鎖的線程釋放鎖之后，下一個線程才可以訪問。而樂觀鎖采取了一種寬泛的態(tài)度，通過某種方式不加鎖來處理資源，比如通過給記錄加 version 來獲取數(shù)據(jù)，性能較悲觀鎖有很大的提高。

CAS 操作包含三個操作數(shù) —— 內(nèi)存位置（V）、預(yù)期原值（A）和新值(B)。如果內(nèi)存地址里面的值和 A 的值是一樣的，那么就將內(nèi)存里面的值更新成 B。CAS是通過無限循環(huán)來獲取數(shù)據(jù)的，若果在第一輪循環(huán)中，a 線程獲取地址里面的值被b 線程修改了，那么 a 線程需要自旋，到下次循環(huán)才有可能機(jī)會執(zhí)行。

java.util.concurrent.atomic 包下的類大多是使用 CAS 操作來實(shí)現(xiàn)的(AtomicInteger,AtomicBoolean,AtomicLong)。

CAS 的會產(chǎn)生什么問題？

1、ABA 問題：

比如說一個線程 one 從內(nèi)存位置 V 中取出 A，這時候另一個線程 two 也從內(nèi)存中取出 A，并且 two 進(jìn)行了一些操作變成了 B，然后 two 又將 V 位置的數(shù)據(jù)變成 A，這時候線程 one 進(jìn)行 CAS 操作發(fā)現(xiàn)內(nèi)存中仍然是 A，然后 one 操作成功。盡管線程 one 的 CAS 操作成功，但可能存在潛藏的問題。從 Java1.5 開始 JDK 的 atomic包里提供了一個類 AtomicStampedReference 來解決 ABA 問題。

2、循環(huán)時間長開銷大：

對于資源競爭嚴(yán)重（線程沖突嚴(yán)重）的情況，CAS 自旋的概率會比較大，從而浪費(fèi)更多的 CPU 資源，效率低于 synchronized。

3、只能保證一個共享變量的原子操作：

當(dāng)對一個共享變量執(zhí)行操作時，我們可以使用循環(huán) CAS 的方式來保證原子操作，但是對多個共享變量操作時，循環(huán) CAS 就無法保證操作的原子性，這個時候就可以用鎖。

什么是死鎖？

當(dāng)線程 A 持有獨(dú)占鎖a，并嘗試去獲取獨(dú)占鎖 b 的同時，線程 B 持有獨(dú)占鎖 b，并嘗試獲取獨(dú)占鎖 a 的情況下，就會發(fā)生 AB 兩個線程由于互相持有對方需要的鎖，而發(fā)生的阻塞現(xiàn)象，我們稱為死鎖。

產(chǎn)生死鎖的條件是什么？怎么防止死鎖？

產(chǎn)生死鎖的必要條件：

1、互斥條件：所謂互斥就是進(jìn)程在某一時間內(nèi)獨(dú)占資源。

2、請求與保持條件：一個進(jìn)程因請求資源而阻塞時，對已獲得的資源保持不放。

3、不剝奪條件：進(jìn)程已獲得資源，在末使用完之前，不能強(qiáng)行剝奪。

4、循環(huán)等待條件：若干進(jìn)程之間形成一種頭尾相接的循環(huán)等待資源關(guān)系。

這四個條件是死鎖的必要條件，只要系統(tǒng)發(fā)生死鎖，這些條件必然成立，而只要上述條件之一不滿足，就不會發(fā)生死鎖。

理解了死鎖的原因，尤其是產(chǎn)生死鎖的四個必要條件，就可以最大可能地避免、預(yù)防和解除死鎖。

防止死鎖可以采用以下的方法：

盡量使用 tryLock(long timeout, TimeUnit unit)的方法(ReentrantLock、ReentrantReadWriteLock)，設(shè)置超時時間，超時可以退出防止死鎖。
盡量使用 Java. util. concurrent 并發(fā)類代替自己手寫鎖。
盡量降低鎖的使用粒度，盡量不要幾個功能用同一把鎖。
盡量減少同步的代碼塊。

死鎖與活鎖的區(qū)別，死鎖與饑餓的區(qū)別？

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

活鎖：任務(wù)或者執(zhí)行者沒有被阻塞，由于某些條件沒有滿足，導(dǎo)致一直重復(fù)嘗試，失敗，嘗試，失敗。

活鎖和死鎖的區(qū)別在于，處于活鎖的實(shí)體是在不斷的改變狀態(tài)，這就是所謂的“活”，而處于死鎖的實(shí)體表現(xiàn)為等待；活鎖有可能自行解開，死鎖則不能。

饑餓：一個或者多個線程因?yàn)榉N種原因無法獲得所需要的資源，導(dǎo)致一直無法執(zhí)行的狀態(tài)。

Java 中導(dǎo)致饑餓的原因：

1、高優(yōu)先級線程吞噬所有的低優(yōu)先級線程的 CPU 時間。

2、線程被永久堵塞在一個等待進(jìn)入同步塊的狀態(tài)，因?yàn)槠渌€程總是能在它之前持續(xù)地對該同步塊進(jìn)行訪問。

3、線程在等待一個本身也處于永久等待完成的對象(比如調(diào)用這個對象的 wait 方法)，因?yàn)槠渌€程總是被持續(xù)地獲得喚醒。

多線程鎖的升級原理是什么？

在Java中，鎖共有4種狀態(tài)，級別從低到高依次為：無狀態(tài)鎖，偏向鎖，輕量級鎖和重量級鎖狀態(tài)，這幾個狀態(tài)會隨著競爭情況逐漸升級。鎖可以升級但不能降級。

AQS(AbstractQueuedSynchronizer)詳解與源碼分析

AQS 介紹

AQS的全稱為（AbstractQueuedSynchronizer），這個類在java.util.concurrent.locks包下面。

AQS是一個用來構(gòu)建鎖和同步器的框架，使用AQS能簡單且高效地構(gòu)造出應(yīng)用廣泛的大量的同步器，比如我們提到的ReentrantLock，Semaphore，其他的諸如ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的。當(dāng)然，我們自己也能利用AQS非常輕松容易地構(gòu)造出符合我們自己需求的同步器。

AQS 原理分析

下面大部分內(nèi)容其實(shí)在AQS類注釋上已經(jīng)給出了，不過是英語看著比較吃力一點(diǎn)，感興趣的話可以看看源碼。

AQS 原理概覽

AQS核心思想是，如果被請求的共享資源空閑，則將當(dāng)前請求資源的線程設(shè)置為有效的工作線程，并且將共享資源設(shè)置為鎖定狀態(tài)。如果被請求的共享資源被占用，那么就需要一套線程阻塞等待以及被喚醒時鎖分配的機(jī)制，這個機(jī)制AQS是用CLH隊(duì)列鎖實(shí)現(xiàn)的，即將暫時獲取不到鎖的線程加入到隊(duì)列中。

CLH(Craig,Landin,and Hagersten)隊(duì)列是一個虛擬的雙向隊(duì)列（虛擬的雙向隊(duì)列即不存在隊(duì)列實(shí)例，僅存在結(jié)點(diǎn)之間的關(guān)聯(lián)關(guān)系）。AQS是將每條請求共享資源的線程封裝成一個CLH鎖隊(duì)列的一個結(jié)點(diǎn)（Node）來實(shí)現(xiàn)鎖的分配。

看個AQS(AbstractQueuedSynchronizer)原理圖：

AQS使用一個int成員變量來表示同步狀態(tài)，通過內(nèi)置的FIFO隊(duì)列來完成獲取資源線程的排隊(duì)工作。AQS使用CAS對該同步狀態(tài)進(jìn)行原子操作實(shí)現(xiàn)對其值的修改。

private volatile int state;//共享變量，使用volatile修飾保證線程可見性

狀態(tài)信息通過protected類型的getState，setState，compareAndSetState進(jìn)行操作

//返回同步狀態(tài)的當(dāng)前值protected final int getState() { return state;} // 設(shè)置同步狀態(tài)的值protected final void setState(int newState) { state = newState;}//原子地（CAS操作）將同步狀態(tài)值設(shè)置為給定值update如果當(dāng)前同步狀態(tài)的值等于expect（期望值）protected final boolean compareAndSetState(int expect, int update) { return unsafe.compareAndSwapInt(this, stateOffset, expect, update);}

AQS 對資源的共享方式

AQS定義兩種資源共享方式

Exclusive（獨(dú)占）：只有一個線程能執(zhí)行，如ReentrantLock。又可分為公平鎖和非公平鎖：

?
公平鎖：按照線程在隊(duì)列中的排隊(duì)順序，先到者先拿到鎖
非公平鎖：當(dāng)線程要獲取鎖時，無視隊(duì)列順序直接去搶鎖，誰搶到就是誰的
Share（共享）：多個線程可同時執(zhí)行，如Semaphore/CountDownLatch。Semaphore、CountDownLatch、 CyclicBarrier、ReadWriteLock 我們都會在后面講到。

ReentrantReadWriteLock 可以看成是組合式，因?yàn)镽eentrantReadWriteLock也就是讀寫鎖允許多個線程同時對某一資源進(jìn)行讀。

不同的自定義同步器爭用共享資源的方式也不同。自定義同步器在實(shí)現(xiàn)時只需要實(shí)現(xiàn)共享資源 state 的獲取與釋放方式即可，至于具體線程等待隊(duì)列的維護(hù)（如獲取資源失敗入隊(duì)/喚醒出隊(duì)等），AQS已經(jīng)在頂層實(shí)現(xiàn)好了。

AQS底層使用了模板方法模式

同步器的設(shè)計(jì)是基于模板方法模式的，如果需要自定義同步器一般的方式是這樣（模板方法模式很經(jīng)典的一個應(yīng)用）：

使用者繼承AbstractQueuedSynchronizer并重寫指定的方法。（這些重寫方法很簡單，無非是對于共享資源state的獲取和釋放）

將AQS組合在自定義同步組件的實(shí)現(xiàn)中，并調(diào)用其模板方法，而這些模板方法會調(diào)用使用者重寫的方法。

這和我們以往通過實(shí)現(xiàn)接口的方式有很大區(qū)別，這是模板方法模式很經(jīng)典的一個運(yùn)用。

AQS使用了模板方法模式，自定義同步器時需要重寫下面幾個AQS提供的模板方法：

isHeldExclusively()//該線程是否正在獨(dú)占資源。只有用到condition才需要去實(shí)現(xiàn)它。tryAcquire(int)//獨(dú)占方式。嘗試獲取資源，成功則返回true，失敗則返回false。tryRelease(int)//獨(dú)占方式。嘗試釋放資源，成功則返回true，失敗則返回false。tryAcquireShared(int)//共享方式。嘗試獲取資源。負(fù)數(shù)表示失敗；0表示成功，但沒有剩余可用資源；正數(shù)表示成功，且有剩余資源。tryReleaseShared(int)//共享方式。嘗試釋放資源，成功則返回true，失敗則返回false。

默認(rèn)情況下，每個方法都拋出 UnsupportedOperationException。這些方法的實(shí)現(xiàn)必須是內(nèi)部線程安全的，并且通常應(yīng)該簡短而不是阻塞。AQS類中的其他方法都是final ，所以無法被其他類使用，只有這幾個方法可以被其他類使用。

以ReentrantLock為例，state初始化為0，表示未鎖定狀態(tài)。A線程lock()時，會調(diào)用tryAcquire()獨(dú)占該鎖并將state+1。此后，其他線程再tryAcquire()時就會失敗，直到A線程unlock()到state=0（即釋放鎖）為止，其它線程才有機(jī)會獲取該鎖。當(dāng)然，釋放鎖之前，A線程自己是可以重復(fù)獲取此鎖的（state會累加），這就是可重入的概念。但要注意，獲取多少次就要釋放多么次，這樣才能保證state是能回到零態(tài)的。

再以CountDownLatch以例，任務(wù)分為N個子線程去執(zhí)行，state也初始化為N（注意N要與線程個數(shù)一致）。這N個子線程是并行執(zhí)行的，每個子線程執(zhí)行完后countDown()一次，state會CAS(Compare and Swap)減1。等到所有子線程都執(zhí)行完后(即state=0)，會unpark()主調(diào)用線程，然后主調(diào)用線程就會從await()函數(shù)返回，繼續(xù)后余動作。

一般來說，自定義同步器要么是獨(dú)占方法，要么是共享方式，他們也只需實(shí)現(xiàn)tryAcquire-tryRelease、tryAcquireShared-tryReleaseShared中的一種即可。但AQS也支持自定義同步器同時實(shí)現(xiàn)獨(dú)占和共享兩種方式，如ReentrantReadWriteLock。

ReentrantLock(重入鎖)實(shí)現(xiàn)原理與公平鎖非公平鎖區(qū)別

什么是可重入鎖（ReentrantLock）？

ReentrantLock重入鎖，是實(shí)現(xiàn)Lock接口的一個類，也是在實(shí)際編程中使用頻率很高的一個鎖，支持重入性，表示能夠?qū)蚕碣Y源能夠重復(fù)加鎖，即當(dāng)前線程獲取該鎖再次獲取不會被阻塞。

在java關(guān)鍵字synchronized隱式支持重入性，synchronized通過獲取自增，釋放自減的方式實(shí)現(xiàn)重入。與此同時，ReentrantLock還支持公平鎖和非公平鎖兩種方式。那么，要想完完全全的弄懂ReentrantLock的話，主要也就是ReentrantLock同步語義的學(xué)習(xí)：1. 重入性的實(shí)現(xiàn)原理；2. 公平鎖和非公平鎖。

重入性的實(shí)現(xiàn)原理

要想支持重入性，就要解決兩個問題：1. 在線程獲取鎖的時候，如果已經(jīng)獲取鎖的線程是當(dāng)前線程的話則直接再次獲取成功；2. 由于鎖會被獲取n次，那么只有鎖在被釋放同樣的n次之后，該鎖才算是完全釋放成功。

ReentrantLock支持兩種鎖：公平鎖和非公平鎖。何謂公平性，是針對獲取鎖而言的，如果一個鎖是公平的，那么鎖的獲取順序就應(yīng)該符合請求上的絕對時間順序，滿足FIFO。

讀寫鎖ReentrantReadWriteLock源碼分析

ReadWriteLock 是什么

首先明確一下，不是說 ReentrantLock 不好，只是 ReentrantLock 某些時候有局限。如果使用 ReentrantLock，可能本身是為了防止線程 A 在寫數(shù)據(jù)、線程 B 在讀數(shù)據(jù)造成的數(shù)據(jù)不一致，但這樣，如果線程 C 在讀數(shù)據(jù)、線程 D 也在讀數(shù)據(jù)，讀數(shù)據(jù)是不會改變數(shù)據(jù)的，沒有必要加鎖，但是還是加鎖了，降低了程序的性能。因?yàn)檫@個，才誕生了讀寫鎖 ReadWriteLock。

ReadWriteLock 是一個讀寫鎖接口，讀寫鎖是用來提升并發(fā)程序性能的鎖分離技術(shù)，ReentrantReadWriteLock 是 ReadWriteLock 接口的一個具體實(shí)現(xiàn)，實(shí)現(xiàn)了讀寫的分離，讀鎖是共享的，寫鎖是獨(dú)占的，讀和讀之間不會互斥，讀和寫、寫和讀、寫和寫之間才會互斥，提升了讀寫的性能。

而讀寫鎖有以下三個重要的特性：

（1）公平選擇性：支持非公平（默認(rèn)）和公平的鎖獲取方式，吞吐量還是非公平優(yōu)于公平。

（2）重進(jìn)入：讀鎖和寫鎖都支持線程重進(jìn)入。

（3）鎖降級：遵循獲取寫鎖、獲取讀鎖再釋放寫鎖的次序，寫鎖能夠降級成為讀鎖。

Condition源碼分析與等待通知機(jī)制

LockSupport詳解

并發(fā)容器

并發(fā)容器之ConcurrentHashMap詳解(JDK1.8版本)與源碼分析

什么是ConcurrentHashMap？

ConcurrentHashMap是Java中的一個線程安全且高效的HashMap實(shí)現(xiàn)。平時涉及高并發(fā)如果要用map結(jié)構(gòu)，那第一時間想到的就是它。相對于hashmap來說，ConcurrentHashMap就是線程安全的map，其中利用了鎖分段的思想提高了并發(fā)度。

那么它到底是如何實(shí)現(xiàn)線程安全的？

JDK 1.6版本關(guān)鍵要素：

segment繼承了ReentrantLock充當(dāng)鎖的角色，為每一個segment提供了線程安全的保障；
segment維護(hù)了哈希散列表的若干個桶，每個桶由HashEntry構(gòu)成的鏈表。

JDK1.8后，ConcurrentHashMap拋棄了原有的Segment 分段鎖，而采用了 CAS + synchronized 來保證并發(fā)安全性。

Java 中 ConcurrentHashMap 的并發(fā)度是什么？

ConcurrentHashMap 把實(shí)際 map 劃分成若干部分來實(shí)現(xiàn)它的可擴(kuò)展性和線程安全。這種劃分是使用并發(fā)度獲得的，它是 ConcurrentHashMap 類構(gòu)造函數(shù)的一個可選參數(shù)，默認(rèn)值為 16，這樣在多線程情況下就能避免爭用。

在 JDK8 后，它摒棄了 Segment（鎖段）的概念，而是啟用了一種全新的方式實(shí)現(xiàn),利用 CAS 算法。同時加入了更多的輔助變量來提高并發(fā)度，具體內(nèi)容還是查看源碼吧。

什么是并發(fā)容器的實(shí)現(xiàn)？

何為同步容器：可以簡單地理解為通過 synchronized 來實(shí)現(xiàn)同步的容器，如果有多個線程調(diào)用同步容器的方法，它們將會串行執(zhí)行。比如 Vector，Hashtable，以及 Collections.synchronizedSet，synchronizedList 等方法返回的容器。可以通過查看 Vector，Hashtable 等這些同步容器的實(shí)現(xiàn)代碼，可以看到這些容器實(shí)現(xiàn)線程安全的方式就是將它們的狀態(tài)封裝起來，并在需要同步的方法上加上關(guān)鍵字 synchronized。

并發(fā)容器使用了與同步容器完全不同的加鎖策略來提供更高的并發(fā)性和伸縮性，例如在 ConcurrentHashMap 中采用了一種粒度更細(xì)的加鎖機(jī)制，可以稱為分段鎖，在這種鎖機(jī)制下，允許任意數(shù)量的讀線程并發(fā)地訪問 map，并且執(zhí)行讀操作的線程和寫操作的線程也可以并發(fā)的訪問 map，同時允許一定數(shù)量的寫操作線程并發(fā)地修改 map，所以它可以在并發(fā)環(huán)境下實(shí)現(xiàn)更高的吞吐量。

Java 中的同步集合與并發(fā)集合有什么區(qū)別？

同步集合與并發(fā)集合都為多線程和并發(fā)提供了合適的線程安全的集合，不過并發(fā)集合的可擴(kuò)展性更高。在 Java1.5 之前程序員們只有同步集合來用且在多線程并發(fā)的時候會導(dǎo)致爭用，阻礙了系統(tǒng)的擴(kuò)展性。Java5 介紹了并發(fā)集合像ConcurrentHashMap，不僅提供線程安全還用鎖分離和內(nèi)部分區(qū)等現(xiàn)代技術(shù)提高了可擴(kuò)展性。

SynchronizedMap 和 ConcurrentHashMap 有什么區(qū)別？

SynchronizedMap 一次鎖住整張表來保證線程安全，所以每次只能有一個線程來訪為 map。

ConcurrentHashMap 使用分段鎖來保證在多線程下的性能。

ConcurrentHashMap 中則是一次鎖住一個桶。ConcurrentHashMap 默認(rèn)將hash 表分為 16 個桶，諸如 get，put，remove 等常用操作只鎖當(dāng)前需要用到的桶。

這樣，原來只能一個線程進(jìn)入，現(xiàn)在卻能同時有 16 個寫線程執(zhí)行，并發(fā)性能的提升是顯而易見的。

另外 ConcurrentHashMap 使用了一種不同的迭代方式。在這種迭代方式中，當(dāng)iterator 被創(chuàng)建后集合再發(fā)生改變就不再是拋出ConcurrentModificationException，取而代之的是在改變時 new 新的數(shù)據(jù)從而不影響原有的數(shù)據(jù)，iterator 完成后再將頭指針替換為新的數(shù)據(jù) ，這樣 iterator線程可以使用原來老的數(shù)據(jù)，而寫線程也可以并發(fā)的完成改變。

并發(fā)容器之CopyOnWriteArrayList詳解

CopyOnWriteArrayList 是什么，可以用于什么應(yīng)用場景？有哪些優(yōu)缺點(diǎn)？

CopyOnWriteArrayList 是一個并發(fā)容器。有很多人稱它是線程安全的，我認(rèn)為這句話不嚴(yán)謹(jǐn)，缺少一個前提條件，那就是非復(fù)合場景下操作它是線程安全的。

CopyOnWriteArrayList(免鎖容器)的好處之一是當(dāng)多個迭代器同時遍歷和修改這個列表時，不會拋出 ConcurrentModificationException。在CopyOnWriteArrayList 中，寫入將導(dǎo)致創(chuàng)建整個底層數(shù)組的副本，而源數(shù)組將保留在原地，使得復(fù)制的數(shù)組在被修改時，讀取操作可以安全地執(zhí)行。

CopyOnWriteArrayList 的使用場景

通過源碼分析，我們看出它的優(yōu)缺點(diǎn)比較明顯，所以使用場景也就比較明顯。就是合適讀多寫少的場景。

CopyOnWriteArrayList 的缺點(diǎn)

由于寫操作的時候，需要拷貝數(shù)組，會消耗內(nèi)存，如果原數(shù)組的內(nèi)容比較多的情況下，可能導(dǎo)致 young gc 或者 full gc。
不能用于實(shí)時讀的場景，像拷貝數(shù)組、新增元素都需要時間，所以調(diào)用一個 set 操作后，讀取到數(shù)據(jù)可能還是舊的，雖然CopyOnWriteArrayList 能做到最終一致性,但是還是沒法滿足實(shí)時性要求。
由于實(shí)際使用中可能沒法保證 CopyOnWriteArrayList 到底要放置多少數(shù)據(jù)，萬一數(shù)據(jù)稍微有點(diǎn)多，每次 add/set 都要重新復(fù)制數(shù)組，這個代價實(shí)在太高昂了。在高性能的互聯(lián)網(wǎng)應(yīng)用中，這種操作分分鐘引起故障。

CopyOnWriteArrayList 的設(shè)計(jì)思想

讀寫分離，讀和寫分開

最終一致性

使用另外開辟空間的思路，來解決并發(fā)沖突

并發(fā)容器之ThreadLocal詳解

ThreadLocal 是什么？有哪些使用場景？

ThreadLocal 是一個本地線程副本變量工具類，在每個線程中都創(chuàng)建了一個 ThreadLocalMap 對象，簡單說 ThreadLocal 就是一種以空間換時間的做法，每個線程可以訪問自己內(nèi)部 ThreadLocalMap 對象內(nèi)的 value。通過這種方式，避免資源在多線程間共享。

原理：線程局部變量是局限于線程內(nèi)部的變量，屬于線程自身所有，不在多個線程間共享。Java提供ThreadLocal類來支持線程局部變量，是一種實(shí)現(xiàn)線程安全的方式。但是在管理環(huán)境下（如 web 服務(wù)器）使用線程局部變量的時候要特別小心，在這種情況下，工作線程的生命周期比任何應(yīng)用變量的生命周期都要長。任何線程局部變量一旦在工作完成后沒有釋放，Java 應(yīng)用就存在內(nèi)存泄露的風(fēng)險。

經(jīng)典的使用場景是為每個線程分配一個 JDBC 連接 Connection。這樣就可以保證每個線程的都在各自的 Connection 上進(jìn)行數(shù)據(jù)庫的操作，不會出現(xiàn) A 線程關(guān)了 B線程正在使用的 Connection；還有 Session 管理等問題。

ThreadLocal 使用例子：

public class TestThreadLocal { //線程本地存儲變量 private static final ThreadLocal<Integer> THREAD_LOCAL_NUM = new ThreadLocal<Integer>() { @Override protected Integer initialValue() { return 0; } }; public static void main(String[] args) { for (int i = 0; i <3; i++) {//啟動三個線程 Thread t = new Thread() { @Override public void run() { add10ByThreadLocal(); } }; t.start(); } } /** * 線程本地存儲變量加 5 */ private static void add10ByThreadLocal() { for (int i = 0; i <5; i++) { Integer n = THREAD_LOCAL_NUM.get(); n += 1; THREAD_LOCAL_NUM.set(n); System.out.println(Thread.currentThread().getName() + " : ThreadLocal num=" + n); } } }

打印結(jié)果：啟動了 3 個線程，每個線程最后都打印到 “ThreadLocal num=5”，而不是 num 一直在累加直到值等于 15

Thread-0 : ThreadLocal num=1Thread-1 : ThreadLocal num=1Thread-0 : ThreadLocal num=2Thread-0 : ThreadLocal num=3Thread-1 : ThreadLocal num=2Thread-2 : ThreadLocal num=1Thread-0 : ThreadLocal num=4Thread-2 : ThreadLocal num=2Thread-1 : ThreadLocal num=3Thread-1 : ThreadLocal num=4Thread-2 : ThreadLocal num=3Thread-0 : ThreadLocal num=5Thread-2 : ThreadLocal num=4Thread-2 : ThreadLocal num=5Thread-1 : ThreadLocal num=5

什么是線程局部變量？

線程局部變量是局限于線程內(nèi)部的變量，屬于線程自身所有，不在多個線程間共享。Java 提供 ThreadLocal 類來支持線程局部變量，是一種實(shí)現(xiàn)線程安全的方式。但是在管理環(huán)境下（如 web 服務(wù)器）使用線程局部變量的時候要特別小心，在這種情況下，工作線程的生命周期比任何應(yīng)用變量的生命周期都要長。任何線程局部變量一旦在工作完成后沒有釋放，Java 應(yīng)用就存在內(nèi)存泄露的風(fēng)險。

ThreadLocal內(nèi)存泄漏分析與解決方案

ThreadLocal造成內(nèi)存泄漏的原因？

ThreadLocalMap 中使用的 key 為 ThreadLocal 的弱引用,而 value 是強(qiáng)引用。所以，如果 ThreadLocal 沒有被外部強(qiáng)引用的情況下，在垃圾回收的時候，key 會被清理掉，而 value 不會被清理掉。這樣一來，ThreadLocalMap 中就會出現(xiàn)key為null的Entry。假如我們不做任何措施的話，value 永遠(yuǎn)無法被GC 回收，這個時候就可能會產(chǎn)生內(nèi)存泄露。ThreadLocalMap實(shí)現(xiàn)中已經(jīng)考慮了這種情況，在調(diào)用 set()、get()、remove() 方法的時候，會清理掉 key 為 null 的記錄。使用完 ThreadLocal方法后最好手動調(diào)用remove()方法

ThreadLocal內(nèi)存泄漏解決方案？

每次使用完ThreadLocal，都調(diào)用它的remove()方法，清除數(shù)據(jù)。
在使用線程池的情況下，沒有及時清理ThreadLocal，不僅是內(nèi)存泄漏的問題，更嚴(yán)重的是可能導(dǎo)致業(yè)務(wù)邏輯出現(xiàn)問題。所以，使用ThreadLocal就跟加鎖完要解鎖一樣，用完就清理。

并發(fā)容器之BlockingQueue詳解

什么是阻塞隊(duì)列？阻塞隊(duì)列的實(shí)現(xiàn)原理是什么？如何使用阻塞隊(duì)列來實(shí)現(xiàn)生產(chǎn)者-消費(fèi)者模型？

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

這兩個附加的操作是：在隊(duì)列為空時，獲取元素的線程會等待隊(duì)列變?yōu)榉强铡．?dāng)隊(duì)列滿時，存儲元素的線程會等待隊(duì)列可用。

阻塞隊(duì)列常用于生產(chǎn)者和消費(fèi)者的場景，生產(chǎn)者是往隊(duì)列里添加元素的線程，消費(fèi)者是從隊(duì)列里拿元素的線程。阻塞隊(duì)列就是生產(chǎn)者存放元素的容器，而消費(fèi)者也只從容器里拿元素。

JDK7 提供了 7 個阻塞隊(duì)列。分別是：

ArrayBlockingQueue ：一個由數(shù)組結(jié)構(gòu)組成的有界阻塞隊(duì)列。

LinkedBlockingQueue ：一個由鏈表結(jié)構(gòu)組成的有界阻塞隊(duì)列。

PriorityBlockingQueue ：一個支持優(yōu)先級排序的無界阻塞隊(duì)列。

DelayQueue：一個使用優(yōu)先級隊(duì)列實(shí)現(xiàn)的無界阻塞隊(duì)列。

SynchronousQueue：一個不存儲元素的阻塞隊(duì)列。

LinkedTransferQueue：一個由鏈表結(jié)構(gòu)組成的無界阻塞隊(duì)列。

LinkedBlockingDeque：一個由鏈表結(jié)構(gòu)組成的雙向阻塞隊(duì)列。

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

BlockingQueue 接口是 Queue 的子接口，它的主要用途并不是作為容器，而是作為線程同步的的工具，因此他具有一個很明顯的特性，當(dāng)生產(chǎn)者線程試圖向 BlockingQueue 放入元素時，如果隊(duì)列已滿，則線程被阻塞，當(dāng)消費(fèi)者線程試圖從中取出一個元素時，如果隊(duì)列為空，則該線程會被阻塞，正是因?yàn)樗哂羞@個特性，所以在程序中多個線程交替向 BlockingQueue 中放入元素，取出元素，它可以很好的控制線程之間的通信。

阻塞隊(duì)列使用最經(jīng)典的場景就是 socket 客戶端數(shù)據(jù)的讀取和解析，讀取數(shù)據(jù)的線程不斷將數(shù)據(jù)放入隊(duì)列，然后解析線程不斷從隊(duì)列取數(shù)據(jù)解析。

并發(fā)容器之ConcurrentLinkedQueue詳解與源碼分析

并發(fā)容器之ArrayBlockingQueue與LinkedBlockingQueue詳解

線程池

Executors類創(chuàng)建四種常見線程池

什么是線程池？有哪幾種創(chuàng)建方式？

池化技術(shù)相比大家已經(jīng)屢見不鮮了，線程池、數(shù)據(jù)庫連接池、Http 連接池等等都是對這個思想的應(yīng)用。池化技術(shù)的思想主要是為了減少每次獲取資源的消耗，提高對資源的利用率。

在面向?qū)ο缶幊讨?#xff0c;創(chuàng)建和銷毀對象是很費(fèi)時間的，因?yàn)閯?chuàng)建一個對象要獲取內(nèi)存資源或者其它更多資源。在 Java 中更是如此，虛擬機(jī)將試圖跟蹤每一個對象，以便能夠在對象銷毀后進(jìn)行垃圾回收。所以提高服務(wù)程序效率的一個手段就是盡可能減少創(chuàng)建和銷毀對象的次數(shù)，特別是一些很耗資源的對象創(chuàng)建和銷毀，這就是”池化資源”技術(shù)產(chǎn)生的原因。

線程池顧名思義就是事先創(chuàng)建若干個可執(zhí)行的線程放入一個池（容器）中，需要的時候從池中獲取線程不用自行創(chuàng)建，使用完畢不需要銷毀線程而是放回池中，從而減少創(chuàng)建和銷毀線程對象的開銷。Java 5+中的 Executor 接口定義一個執(zhí)行線程的工具。它的子類型即線程池接口是 ExecutorService。要配置一個線程池是比較復(fù)雜的，尤其是對于線程池的原理不是很清楚的情況下，因此在工具類 Executors 面提供了一些靜態(tài)工廠方法，生成一些常用的線程池，如下所示：

（1）newSingleThreadExecutor：創(chuàng)建一個單線程的線程池。這個線程池只有一個線程在工作，也就是相當(dāng)于單線程串行執(zhí)行所有任務(wù)。如果這個唯一的線程因?yàn)楫惓＝Y(jié)束，那么會有一個新的線程來替代它。此線程池保證所有任務(wù)的執(zhí)行順序按照任務(wù)的提交順序執(zhí)行。

（2）newFixedThreadPool：創(chuàng)建固定大小的線程池。每次提交一個任務(wù)就創(chuàng)建一個線程，直到線程達(dá)到線程池的最大大小。線程池的大小一旦達(dá)到最大值就會保持不變，如果某個線程因?yàn)閳?zhí)行異常而結(jié)束，那么線程池會補(bǔ)充一個新線程。如果希望在服務(wù)器上使用線程池，建議使用 newFixedThreadPool方法來創(chuàng)建線程池，這樣能獲得更好的性能。

（3） newCachedThreadPool：創(chuàng)建一個可緩存的線程池。如果線程池的大小超過了處理任務(wù)所需要的線程，那么就會回收部分空閑（60 秒不執(zhí)行任務(wù)）的線程，當(dāng)任務(wù)數(shù)增加時，此線程池又可以智能的添加新線程來處理任務(wù)。此線程池不會對線程池大小做限制，線程池大小完全依賴于操作系統(tǒng)（或者說 JVM）能夠創(chuàng)建的最大線程大小。

（4）newScheduledThreadPool：創(chuàng)建一個大小無限的線程池。此線程池支持定時以及周期性執(zhí)行任務(wù)的需求。

線程池有什么優(yōu)點(diǎn)？

降低資源消耗：重用存在的線程，減少對象創(chuàng)建銷毀的開銷。

?
提高響應(yīng)速度。可有效的控制最大并發(fā)線程數(shù)，提高系統(tǒng)資源的使用率，同時避免過多資源競爭，避免堵塞。當(dāng)任務(wù)到達(dá)時，任務(wù)可以不需要的等到線程創(chuàng)建就能立即執(zhí)行。

?
提高線程的可管理性。線程是稀缺資源，如果無限制的創(chuàng)建，不僅會消耗系統(tǒng)資源，還會降低系統(tǒng)的穩(wěn)定性，使用線程池可以進(jìn)行統(tǒng)一的分配，調(diào)優(yōu)和監(jiān)控。
?
附加功能：提供定時執(zhí)行、定期執(zhí)行、單線程、并發(fā)數(shù)控制等功能。

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

線程池都有哪些狀態(tài)？

RUNNING：這是最正常的狀態(tài)，接受新的任務(wù)，處理等待隊(duì)列中的任務(wù)。
SHUTDOWN：不接受新的任務(wù)提交，但是會繼續(xù)處理等待隊(duì)列中的任務(wù)。
STOP：不接受新的任務(wù)提交，不再處理等待隊(duì)列中的任務(wù)，中斷正在執(zhí)行任務(wù)的線程。
TIDYING：所有的任務(wù)都銷毀了，workCount 為 0，線程池的狀態(tài)在轉(zhuǎn)換為 TIDYING 狀態(tài)時，會執(zhí)行鉤子方法 terminated()。
TERMINATED：terminated()方法結(jié)束后，線程池的狀態(tài)就會變成這個。

什么是 Executor 框架？為什么使用 Executor 框架？

Executor 框架是一個根據(jù)一組執(zhí)行策略調(diào)用，調(diào)度，執(zhí)行和控制的異步任務(wù)的框架。

每次執(zhí)行任務(wù)創(chuàng)建線程 new Thread()比較消耗性能，創(chuàng)建一個線程是比較耗時、耗資源的，而且無限制的創(chuàng)建線程會引起應(yīng)用程序內(nèi)存溢出。

所以創(chuàng)建一個線程池是個更好的的解決方案，因?yàn)榭梢韵拗凭€程的數(shù)量并且可以回收再利用這些線程。利用Executors 框架可以非常方便的創(chuàng)建一個線程池。

在 Java 中 Executor 和 Executors 的區(qū)別？

Executors 工具類的不同方法按照我們的需求創(chuàng)建了不同的線程池，來滿足業(yè)務(wù)的需求。

?
Executor 接口對象能執(zhí)行我們的線程任務(wù)。

?
ExecutorService 接口繼承了 Executor 接口并進(jìn)行了擴(kuò)展，提供了更多的方法我們能獲得任務(wù)執(zhí)行的狀態(tài)并且可以獲取任務(wù)的返回值。
?
使用 ThreadPoolExecutor 可以創(chuàng)建自定義線程池。

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

線程池中 submit() 和 execute() 方法有什么區(qū)別？

接收參數(shù)：execute()只能執(zhí)行 Runnable 類型的任務(wù)。submit()可以執(zhí)行 Runnable 和 Callable 類型的任務(wù)。

返回值：submit()方法可以返回持有計(jì)算結(jié)果的 Future 對象，而execute()沒有

異常處理：submit()方便Exception處理

什么是線程組，為什么在 Java 中不推薦使用？

ThreadGroup 類，可以把線程歸屬到某一個線程組中，線程組中可以有線程對象，也可以有線程組，組中還可以有線程，這樣的組織結(jié)構(gòu)有點(diǎn)類似于樹的形式。

線程組和線程池是兩個不同的概念，他們的作用完全不同，前者是為了方便線程的管理，后者是為了管理線程的生命周期，復(fù)用線程，減少創(chuàng)建銷毀線程的開銷。

為什么不推薦使用線程組？因?yàn)槭褂糜泻芏嗟陌踩[患吧，沒有具體追究，如果需要使用，推薦使用線程池。

線程池之ThreadPoolExecutor詳解

Executors和ThreaPoolExecutor創(chuàng)建線程池的區(qū)別

《阿里巴巴Java開發(fā)手冊》中強(qiáng)制線程池不允許使用 Executors 去創(chuàng)建，而是通過 ThreadPoolExecutor 的方式，這樣的處理方式讓寫的同學(xué)更加明確線程池的運(yùn)行規(guī)則，規(guī)避資源耗盡的風(fēng)險

Executors 各個方法的弊端：

newFixedThreadPool 和 newSingleThreadExecutor:

主要問題是堆積的請求處理隊(duì)列可能會耗費(fèi)非常大的內(nèi)存，甚至 OOM。

?
newCachedThreadPool 和 newScheduledThreadPool:

主要問題是線程數(shù)最大數(shù)是 Integer.MAX_VALUE，可能會創(chuàng)建數(shù)量非常多的線程，甚至 OOM。

ThreaPoolExecutor創(chuàng)建線程池方式只有一種，就是走它的構(gòu)造函數(shù)，參數(shù)自己指定

你知道怎么創(chuàng)建線程池嗎？

創(chuàng)建線程池的方式有多種，這里你只需要答 ThreadPoolExecutor 即可。

ThreadPoolExecutor() 是最原始的線程池創(chuàng)建，也是阿里巴巴 Java 開發(fā)手冊中明確規(guī)范的創(chuàng)建線程池的方式。

ThreadPoolExecutor構(gòu)造函數(shù)重要參數(shù)分析

ThreadPoolExecutor 3 個最重要的參數(shù)：

corePoolSize?：核心線程數(shù)，線程數(shù)定義了最小可以同時運(yùn)行的線程數(shù)量。
maximumPoolSize?：線程池中允許存在的工作線程的最大數(shù)量
workQueue：當(dāng)新任務(wù)來的時候會先判斷當(dāng)前運(yùn)行的線程數(shù)量是否達(dá)到核心線程數(shù)，如果達(dá)到的話，任務(wù)就會被存放在隊(duì)列中。

ThreadPoolExecutor其他常見參數(shù):

keepAliveTime：線程池中的線程數(shù)量大于 corePoolSize 的時候，如果這時沒有新的任務(wù)提交，核心線程外的線程不會立即銷毀，而是會等待，直到等待的時間超過了 keepAliveTime才會被回收銷毀；

unit ：keepAliveTime 參數(shù)的時間單位。

threadFactory：為線程池提供創(chuàng)建新線程的線程工廠

handler ：線程池任務(wù)隊(duì)列超過 maxinumPoolSize 之后的拒絕策略

ThreadPoolExecutor飽和策略

ThreadPoolExecutor?飽和策略定義:

如果當(dāng)前同時運(yùn)行的線程數(shù)量達(dá)到最大線程數(shù)量并且隊(duì)列也已經(jīng)被放滿了任時，ThreadPoolTaskExecutor?定義一些策略:

ThreadPoolExecutor.AbortPolicy：拋出 RejectedExecutionException來拒絕新任務(wù)的處理。
ThreadPoolExecutor.CallerRunsPolicy：調(diào)用執(zhí)行自己的線程運(yùn)行任務(wù)。您不會任務(wù)請求。但是這種策略會降低對于新任務(wù)提交速度，影響程序的整體性能。另外，這個策略喜歡增加隊(duì)列容量。如果您的應(yīng)用程序可以承受此延遲并且你不能任務(wù)丟棄任何一個任務(wù)請求的話，你可以選擇這個策略。
ThreadPoolExecutor.DiscardPolicy：不處理新任務(wù)，直接丟棄掉。
ThreadPoolExecutor.DiscardOldestPolicy：此策略將丟棄最早的未處理的任務(wù)請求。

舉個例子：Spring 通過 ThreadPoolTaskExecutor 或者我們直接通過 ThreadPoolExecutor 的構(gòu)造函數(shù)創(chuàng)建線程池的時候，當(dāng)我們不指定 RejectedExecutionHandler 飽和策略的話來配置線程池的時候默認(rèn)使用的是 ThreadPoolExecutor.AbortPolicy。在默認(rèn)情況下，ThreadPoolExecutor 將拋出 RejectedExecutionException 來拒絕新來的任務(wù) ，這代表你將丟失對這個任務(wù)的處理。對于可伸縮的應(yīng)用程序，建議使用 ThreadPoolExecutor.CallerRunsPolicy。當(dāng)最大池被填滿時，此策略為我們提供可伸縮隊(duì)列。（這個直接查看 ThreadPoolExecutor 的構(gòu)造函數(shù)源碼就可以看出，比較簡單的原因，這里就不貼代碼了）

一個簡單的線程池Demo:Runnable+ThreadPoolExecutor

線程池實(shí)現(xiàn)原理

為了讓大家更清楚上面的面試題中的一些概念，我寫了一個簡單的線程池 Demo。

首先創(chuàng)建一個?Runnable?接口的實(shí)現(xiàn)類（當(dāng)然也可以是?Callable?接口，我們上面也說了兩者的區(qū)別。）

import java.util.Date; /** * 這是一個簡單的Runnable類，需要大約5秒鐘來執(zhí)行其任務(wù)。 */public class MyRunnable implements Runnable { private String command; public MyRunnable(String s) { this.command = s; } @Override public void run() { System.out.println(Thread.currentThread().getName() + " Start. Time = " + new Date()); processCommand(); System.out.println(Thread.currentThread().getName() + " End. Time = " + new Date()); } private void processCommand() { try { Thread.sleep(5000); } catch (InterruptedException e) { e.printStackTrace(); } } @Override public String toString() { return this.command; }}

編寫測試程序，我們這里以阿里巴巴推薦的使用?ThreadPoolExecutor?構(gòu)造函數(shù)自定義參數(shù)的方式來創(chuàng)建線程池。

import java.util.concurrent.ArrayBlockingQueue;import java.util.concurrent.ThreadPoolExecutor;import java.util.concurrent.TimeUnit; public class ThreadPoolExecutorDemo { private static final int CORE_POOL_SIZE = 5; private static final int MAX_POOL_SIZE = 10; private static final int QUEUE_CAPACITY = 100; private static final Long KEEP_ALIVE_TIME = 1L; public static void main(String[] args) { //使用阿里巴巴推薦的創(chuàng)建線程池的方式 //通過ThreadPoolExecutor構(gòu)造函數(shù)自定義參數(shù)創(chuàng)建 ThreadPoolExecutor executor = new ThreadPoolExecutor( CORE_POOL_SIZE, MAX_POOL_SIZE, KEEP_ALIVE_TIME, TimeUnit.SECONDS, new ArrayBlockingQueue<>(QUEUE_CAPACITY), new ThreadPoolExecutor.CallerRunsPolicy()); for (int i = 0; i < 10; i++) { //創(chuàng)建WorkerThread對象（WorkerThread類實(shí)現(xiàn)了Runnable 接口） Runnable worker = new MyRunnable("" + i); //執(zhí)行Runnable executor.execute(worker); } //終止線程池 executor.shutdown(); while (!executor.isTerminated()) { } System.out.println("Finished all threads"); }}

可以看到我們上面的代碼指定了：

corePoolSize: 核心線程數(shù)為 5。

maximumPoolSize ：最大線程數(shù) 10

keepAliveTime : 等待時間為 1L。

unit: 等待時間的單位為 TimeUnit.SECONDS。

workQueue：任務(wù)隊(duì)列為 ArrayBlockingQueue，并且容量為 100;

handler:飽和策略為 CallerRunsPolicy。

Output：

pool-1-thread-2 Start. Time = Tue Nov 12 20:59:44 CST 2019pool-1-thread-5 Start. Time = Tue Nov 12 20:59:44 CST 2019pool-1-thread-4 Start. Time = Tue Nov 12 20:59:44 CST 2019pool-1-thread-1 Start. Time = Tue Nov 12 20:59:44 CST 2019pool-1-thread-3 Start. Time = Tue Nov 12 20:59:44 CST 2019pool-1-thread-5 End. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-3 End. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-2 End. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-4 End. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-1 End. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-2 Start. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-1 Start. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-4 Start. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-3 Start. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-5 Start. Time = Tue Nov 12 20:59:49 CST 2019pool-1-thread-2 End. Time = Tue Nov 12 20:59:54 CST 2019pool-1-thread-3 End. Time = Tue Nov 12 20:59:54 CST 2019pool-1-thread-4 End. Time = Tue Nov 12 20:59:54 CST 2019pool-1-thread-5 End. Time = Tue Nov 12 20:59:54 CST 2019pool-1-thread-1 End. Time = Tue Nov 12 20:59:54 CST 2019

線程池之ScheduledThreadPoolExecutor詳解

FutureTask詳解

原子操作類

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

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

處理器使用基于對緩存加鎖或總線加鎖的方式來實(shí)現(xiàn)多處理器之間的原子操作。在 Java 中可以通過鎖和循環(huán) CAS 的方式來實(shí)現(xiàn)原子操作。CAS 操作——Compare & Set，或是 Compare & Swap，現(xiàn)在幾乎所有的 CPU 指令都支持 CAS 的原子操作。

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

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

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

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

原子類：AtomicBoolean，AtomicInteger，AtomicLong，AtomicReference

原子數(shù)組：AtomicIntegerArray，AtomicLongArray，AtomicReferenceArray

原子屬性更新器：AtomicLongFieldUpdater，AtomicIntegerFieldUpdater，AtomicReferenceFieldUpdater

解決 ABA 問題的原子類：AtomicMarkableReference（通過引入一個 boolean來反映中間有沒有變過），AtomicStampedReference（通過引入一個 int 來累加來反映中間有沒有變過）

說一下 atomic 的原理？

Atomic包中的類基本的特性就是在多線程環(huán)境下，當(dāng)有多個線程同時對單個（包括基本類型及引用類型）變量進(jìn)行操作時，具有排他性，即當(dāng)多個線程同時對該變量的值進(jìn)行更新時，僅有一個線程能成功，而未成功的線程可以向自旋鎖一樣，繼續(xù)嘗試，一直等到執(zhí)行成功。

AtomicInteger 類的部分源碼：

// setup to use Unsafe.compareAndSwapInt for updates（更新操作時提供“比較并替換”的作用）private static final Unsafe unsafe = Unsafe.getUnsafe();private static final long valueOffset; static { try { valueOffset = unsafe.objectFieldOffset (AtomicInteger.class.getDeclaredField("value")); } catch (Exception ex) { throw new Error(ex); }} private volatile int value;

AtomicInteger 類主要利用 CAS (compare and swap) + volatile 和 native 方法來保證原子操作，從而避免 synchronized 的高開銷，執(zhí)行效率大為提升。

CAS的原理是拿期望的值和原本的一個值作比較，如果相同則更新成新的值。UnSafe 類的 objectFieldOffset() 方法是一個本地方法，這個方法是用來拿到“原來的值”的內(nèi)存地址，返回值是 valueOffset。另外 value 是一個volatile變量，在內(nèi)存中可見，因此 JVM 可以保證任何時刻任何線程總能拿到該變量的最新值。

并發(fā)工具

并發(fā)工具之CountDownLatch與CyclicBarrier

在 Java 中 CycliBarriar 和 CountdownLatch 有什么區(qū)別？

CountDownLatch與CyclicBarrier都是用于控制并發(fā)的工具類，都可以理解成維護(hù)的就是一個計(jì)數(shù)器，但是這兩者還是各有不同側(cè)重點(diǎn)的：
CountDownLatch一般用于某個線程A等待若干個其他線程執(zhí)行完任務(wù)之后，它才執(zhí)行；而CyclicBarrier一般用于一組線程互相等待至某個狀態(tài)，然后這一組線程再同時執(zhí)行；CountDownLatch強(qiáng)調(diào)一個線程等多個線程完成某件事情。CyclicBarrier是多個線程互等，等大家都完成，再攜手共進(jìn)。

?
調(diào)用CountDownLatch的countDown方法后，當(dāng)前線程并不會阻塞，會繼續(xù)往下執(zhí)行；而調(diào)用CyclicBarrier的await方法，會阻塞當(dāng)前線程，直到CyclicBarrier指定的線程全部都到達(dá)了指定點(diǎn)的時候，才能繼續(xù)往下執(zhí)行；

?
CountDownLatch方法比較少，操作比較簡單，而CyclicBarrier提供的方法更多，比如能夠通過getNumberWaiting()，isBroken()這些方法獲取當(dāng)前多個線程的狀態(tài)，并且CyclicBarrier的構(gòu)造方法可以傳入barrierAction，指定當(dāng)所有線程都到達(dá)時執(zhí)行的業(yè)務(wù)功能；

?
CountDownLatch是不能復(fù)用的，而CyclicLatch是可以復(fù)用的。

?

并發(fā)工具之Semaphore與Exchanger

Semaphore 有什么作用

Semaphore 就是一個信號量，它的作用是限制某段代碼塊的并發(fā)數(shù)。Semaphore有一個構(gòu)造函數(shù)，可以傳入一個 int 型整數(shù) n，表示某段代碼最多只有 n 個線程可以訪問，如果超出了 n，那么請等待，等到某個線程執(zhí)行完畢這段代碼塊，下一個線程再進(jìn)入。由此可以看出如果 Semaphore 構(gòu)造函數(shù)中傳入的 int 型整數(shù) n=1，相當(dāng)于變成了一個 synchronized 了。

Semaphore(信號量)-允許多個線程同時訪問：synchronized 和 ReentrantLock 都是一次只允許一個線程訪問某個資源，Semaphore(信號量)可以指定多個線程同時訪問某個資源。

什么是線程間交換數(shù)據(jù)的工具Exchanger

Exchanger是一個用于線程間協(xié)作的工具類，用于兩個線程間交換數(shù)據(jù)。它提供了一個交換的同步點(diǎn)，在這個同步點(diǎn)兩個線程能夠交換數(shù)據(jù)。交換數(shù)據(jù)是通過exchange方法來實(shí)現(xiàn)的，如果一個線程先執(zhí)行exchange方法，那么它會同步等待另一個線程也執(zhí)行exchange方法，這個時候兩個線程就都達(dá)到了同步點(diǎn)，兩個線程就可以交換數(shù)據(jù)。

常用的并發(fā)工具類有哪些？

Semaphore(信號量)-允許多個線程同時訪問：synchronized 和 ReentrantLock 都是一次只允許一個線程訪問某個資源，Semaphore(信號量)可以指定多個線程同時訪問某個資源。
CountDownLatch(倒計(jì)時器)：CountDownLatch是一個同步工具類，用來協(xié)調(diào)多個線程之間的同步。這個工具通常用來控制線程等待，它可以讓某一個線程等待直到倒計(jì)時結(jié)束，再開始執(zhí)行。
CyclicBarrier(循環(huán)柵欄)：CyclicBarrier 和 CountDownLatch 非常類似，它也可以實(shí)現(xiàn)線程間的技術(shù)等待，但是它的功能比 CountDownLatch 更加復(fù)雜和強(qiáng)大。主要應(yīng)用場景和 CountDownLatch 類似。CyclicBarrier 的字面意思是可循環(huán)使用（Cyclic）的屏障（Barrier）。它要做的事情是，讓一組線程到達(dá)一個屏障（也可以叫同步點(diǎn)）時被阻塞，直到最后一個線程到達(dá)屏障時，屏障才會開門，所有被屏障攔截的線程才會繼續(xù)干活。CyclicBarrier默認(rèn)的構(gòu)造方法是 CyclicBarrier(int parties)，其參數(shù)表示屏障攔截的線程數(shù)量，每個線程調(diào)用await()方法告訴 CyclicBarrier 我已經(jīng)到達(dá)了屏障，然后當(dāng)前線程被阻塞。

原文鏈接：

https://thinkwon.blog.csdn.net/article/details/104863992

面試專場：

Redis面試題（2020最新版）

Tomcat面試題（2020最新版）

Java虛擬機(jī)(JVM)面試題（2020最新版）

Spring Cloud面試題（2020最新版）

MySQL數(shù)據(jù)庫面試題（2020最新版）

消息中間件MQ與RabbitMQ面試題（2020最新版）

Zookeeper超詳細(xì)的面試題

Java經(jīng)典面試題整理及答案詳解（一）

面試官問：為什么需要消息隊(duì)列？使用消息隊(duì)列有什么好處？

BAT大廠招聘Java 程序員的技術(shù)標(biāo)準(zhǔn)，你達(dá)到要求了嗎？

別再說你不會分布式了，面試官能問的都在這了

Spring MVC 面經(jīng)

Java面試----2018年MyBatis常見實(shí)用面試題整理

《圖解HTTP》面試知道這些就差不多了！

Spring經(jīng)典面試題總結(jié)

面試：史上最全多線程面試題！

總結(jié)

以上是生活随笔為你收集整理的Java并发编程面试题（2020最新版）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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