摘要：是需要我們?nèi)ヌ幚砗芏嗍虑?，為了防止多線程給我們帶來的安全和性能的問題下面就來簡單總結(jié)一下我們需要哪些知識(shí)點(diǎn)來解決多線程遇到的問題。

不小心就鴿了幾天沒有更新了，這個(gè)星期回家咯。在學(xué)校的日子要努力一點(diǎn)才行!

只有光頭才能變強(qiáng)

回顧前面：

多線程三分鐘就可以入個(gè)門了！

Thread源碼剖析

本文章的知識(shí)主要參考《Java并發(fā)編程實(shí)戰(zhàn)》這本書的前4章，這本書的前4章都是講解并發(fā)的基礎(chǔ)的。要是能好好理解這些基礎(chǔ)，那么我們往后的學(xué)習(xí)就會(huì)事半功倍。

當(dāng)然了，《Java并發(fā)編程實(shí)戰(zhàn)》可以說是非常經(jīng)典的一本書。我是未能完全理解的，在這也僅僅是拋磚引玉。想要更加全面地理解我下面所說的知識(shí)點(diǎn)，可以去閱讀一下這本書，總的來說還是不錯(cuò)的。

首先來預(yù)覽一下《Java并發(fā)編程實(shí)戰(zhàn)》前4章的目錄究竟在講什么吧：

第1章　簡介

1.1　并發(fā)簡史

1.2　線程的優(yōu)勢

1.2.1　發(fā)揮多處理器的強(qiáng)大能力

1.2.2　建模的簡單性

1.2.3　異步事件的簡化處理

1.2.4　響應(yīng)更靈敏的用戶界面

1.3　線程帶來的風(fēng)險(xiǎn)

1.3.1　安全性問題

1.3.2　活躍性問題

1.3.3　性能問題

1.4　線程無處不在

ps：這一部分我就不講了，主要是引出我們接下來的知識(shí)點(diǎn)，有興趣的同學(xué)可翻看原書~

第2章　線程安全性

2.1　什么是線程安全性

2.2　原子性

2.2.1　競態(tài)條件

2.2.2　示例：延遲初始化中的競態(tài)條件

2.2.3　復(fù)合操作

2.3　加鎖機(jī)制

2.3.1　內(nèi)置鎖

2.3.2　重入

2.4　用鎖來保護(hù)狀態(tài)

2.5　活躍性與性能

第3章　對(duì)象的共享

3.1　可見性

3.1.1　失效數(shù)據(jù)

3.1.2　非原子的64位操作

3.1.3　加鎖與可見性

3.1.4　Volatile變量

3.2　發(fā)布與逸出

3.3　線程封閉

3.3.1　Ad-hoc線程封閉

3.3.2　棧封閉

3.3.3　ThreadLocal類

3.4　不變性

3.4.1　Final域

3.4.2　示例：使用Volatile類型來發(fā)布不可變對(duì)象

3.5　安全發(fā)布

3.5.1　不正確的發(fā)布：正確的對(duì)象被破壞

3.5.2 　不可變對(duì)象與初始化安全性

3.5.3　安全發(fā)布的常用模式

3.5.4　事實(shí)不可變對(duì)象

3.5.5　可變對(duì)象

3.5.6　安全地共享對(duì)象

第4章　對(duì)象的組合

4.1　設(shè)計(jì)線程安全的類

4.1.1　收集同步需求

4.1.2　依賴狀態(tài)的操作

4.1.3　狀態(tài)的所有權(quán)

4.2　實(shí)例封閉

4.2.1　Java監(jiān)視器模式

4.2.2　示例：車輛追蹤

4.3　線程安全性的委托

4.3.1　示例：基于委托的車輛追蹤器

4.3.2　獨(dú)立的狀態(tài)變量

4.3.3　當(dāng)委托失效時(shí)

4.3.4　發(fā)布底層的狀態(tài)變量

4.3.5　示例：發(fā)布狀態(tài)的車輛追蹤器

4.4　在現(xiàn)有的線程安全類中添加功能

4.4.1　客戶端加鎖機(jī)制

4.4.2　組合

4.5　將同步策略文檔化

那么接下來我們就開始吧~

在前面的文章中已經(jīng)講解了線程【多線程三分鐘就可以入個(gè)門了！】，多線程主要是為了提高我們應(yīng)用程序的使用率。但同時(shí)，這會(huì)給我們帶來很多安全問題！

如果我們在單線程中以“順序”(串行-->獨(dú)占)的方式執(zhí)行代碼是沒有任何問題的。但是到了多線程的環(huán)境下(并行)，如果沒有設(shè)計(jì)和控制得好，就會(huì)給我們帶來很多意想不到的狀況，也就是線程安全性問題

因?yàn)樵诙嗑€程的環(huán)境下，線程是交替執(zhí)行的，一般他們會(huì)使用多個(gè)線程執(zhí)行相同的代碼。如果在此相同的代碼里邊有著共享的變量，或者一些組合操作，我們想要的正確結(jié)果就很容易出現(xiàn)了問題

簡單舉個(gè)例子：

下面的程序在單線程中跑起來，是沒有問題的。

public class UnsafeCountingServlet extends GenericServlet implements Servlet {
    private long count = 0;

    public long getCount() {
        return count;
    }

    public void service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException {

        ++count;
        // To something else...
    }
}

但是在多線程環(huán)境下跑起來，它的count值計(jì)算就不對(duì)了！

首先，它共享了count這個(gè)變量，其次來說++count;這是一個(gè)組合的操作(注意，它并非是原子性）

++count實(shí)際上的操作是這樣子的：

讀取count值

將值+1

將計(jì)算結(jié)果寫入count

于是多線程執(zhí)行的時(shí)候很可能就會(huì)有這樣的情況：

當(dāng)線程A讀取到count的值是8的時(shí)候，同時(shí)線程B也進(jìn)去這個(gè)方法上了，也是讀取到count的值為8

它倆都對(duì)值進(jìn)行加1

將計(jì)算結(jié)果寫入到count上。但是，寫入到count上的結(jié)果是9

也就是說：兩個(gè)線程進(jìn)來了，但是正確的結(jié)果是應(yīng)該返回10，而它返回了9，這是不正常的！

如果說：當(dāng)多個(gè)線程訪問某個(gè)類的時(shí)候，這個(gè)類始終能表現(xiàn)出正確的行為，那么這個(gè)類就是線程安全的！

有個(gè)原則：能使用JDK提供的線程安全機(jī)制，就使用JDK的。

當(dāng)然了，此部分其實(shí)是我們學(xué)習(xí)多線程最重要的環(huán)節(jié)，這里我就不詳細(xì)說了。這里只是一個(gè)總覽，這些知識(shí)點(diǎn)在后面的學(xué)習(xí)中都會(huì)遇到~~~

使用多線程我們的目的就是為了提高應(yīng)用程序的使用率，但是如果多線程的代碼沒有好好設(shè)計(jì)的話，那未必會(huì)提高效率。反而降低了效率，甚至?xí)斐伤梨i！

就比如說我們的Servlet，一個(gè)Servlet對(duì)象可以處理多個(gè)請(qǐng)求的，Servlet顯然是一個(gè)天然支持多線程的。

又以下面的例子來說吧：

public class UnsafeCountingServlet extends GenericServlet implements Servlet {
    private long count = 0;

    public long getCount() {
        return count;
    }

    public void service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException {

        ++count;
        // To something else...
    }
}

從上面我們已經(jīng)說了，上面這個(gè)類是線程不安全的。最簡單的方式：如果我們在service方法上加上JDK為我們提供的內(nèi)置鎖synchronized，那么我們就可以實(shí)現(xiàn)線程安全了。

public class UnsafeCountingServlet extends GenericServlet implements Servlet {
    private long count = 0;

    public long getCount() {
        return count;
    }

    public void synchronized service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException {

        ++count;
        // To something else...
    }
}

雖然實(shí)現(xiàn)了線程安全了，但是這會(huì)帶來很嚴(yán)重的性能問題：

每個(gè)請(qǐng)求都得等待上一個(gè)請(qǐng)求的service方法處理了以后才可以完成對(duì)應(yīng)的操作

這就導(dǎo)致了：我們完成一個(gè)小小的功能，使用了多線程的目的是想要提高效率，但現(xiàn)在沒有把握得當(dāng)，卻帶來嚴(yán)重的性能問題！

在使用多線程的時(shí)候：更嚴(yán)重的時(shí)候還有死鎖(程序就卡住不動(dòng)了)。

這些都是我們接下來要學(xué)習(xí)的地方：學(xué)習(xí)使用哪種同步機(jī)制來實(shí)現(xiàn)線程安全，并且性能是提高了而不是降低了~

書上是這樣定義發(fā)布和逸出的：

發(fā)布(publish) 使對(duì)象能夠在當(dāng)前作用域之外的代碼中使用
逸出(escape) 當(dāng)某個(gè)不應(yīng)該發(fā)布的對(duì)象被發(fā)布了

常見逸出的有下面幾種方式：

靜態(tài)域逸出

public修飾的get方法

方法參數(shù)傳遞

隱式的this

靜態(tài)域逸出：

public修飾get方法：

方法參數(shù)傳遞我就不再演示了，因?yàn)榘褜?duì)象傳遞過去給另外的方法，已經(jīng)是逸出了~

下面來看看該書給出this逸出的例子：

逸出就是本不應(yīng)該發(fā)布對(duì)象的地方，把對(duì)象發(fā)布了。導(dǎo)致我們的數(shù)據(jù)泄露出去了，這就造成了一個(gè)安全隱患！理解起來是不是簡單了一丟丟？

上面談到了好幾種逸出的情況，我們接下來來談?wù)?strong>如何安全發(fā)布對(duì)象。

安全發(fā)布對(duì)象有幾種常見的方式：

在靜態(tài)域中直接初始化 ： public static Person = new Person();

靜態(tài)初始化由JVM在類的初始化階段就執(zhí)行了，JVM內(nèi)部存在著同步機(jī)制，致使這種方式我們可以安全發(fā)布對(duì)象

對(duì)應(yīng)的引用保存到volatile或者AtomicReferance引用中

保證了該對(duì)象的引用的可見性和原子性

由final修飾

該對(duì)象是不可變的，那么線程就一定是安全的，所以是安全發(fā)布~

由鎖來保護(hù)

發(fā)布和使用的時(shí)候都需要加鎖，這樣才保證能夠該對(duì)象不會(huì)逸出

從上面我們就可以看到，使用多線程會(huì)把我們的系統(tǒng)搞得挺復(fù)雜的。是需要我們?nèi)ヌ幚砗芏嗍虑?，為了防止多線程給我們帶來的安全和性能的問題~

下面就來簡單總結(jié)一下我們需要哪些知識(shí)點(diǎn)來解決多線程遇到的問題。

使用多線程就一定要保證我們的線程是安全的，這是最重要的地方！

在Java中，我們一般會(huì)有下面這么幾種辦法來實(shí)現(xiàn)線程安全問題：

無狀態(tài)(沒有共享變量)

使用final使該引用變量不可變(如果該對(duì)象引用也引用了其他的對(duì)象，那么無論是發(fā)布或者使用時(shí)都需要加鎖)

加鎖(內(nèi)置鎖，顯示Lock鎖)

使用JDK為我們提供的類來實(shí)現(xiàn)線程安全(此部分的類就很多了)

原子性（就比如上面的count++操作，可以使用AtomicLong來實(shí)現(xiàn)原子性，那么在增加的時(shí)候就不會(huì)出差錯(cuò)了！)

容器(ConcurrentHashMap等等...)

......

...等等

何為原子性？何為可見性？當(dāng)初我在ConcurrentHashMap基于JDK1.8源碼剖析中已經(jīng)簡單說了一下了。不了解的同學(xué)可以進(jìn)去看看。

在多線程中很多時(shí)候都是因?yàn)槟硞€(gè)操作不是原子性的，使數(shù)據(jù)混亂出錯(cuò)。如果操作的數(shù)據(jù)是原子性的，那么就可以很大程度上避免了線程安全問題了！

count++，先讀取，后自增，再賦值。如果該操作是原子性的，那么就可以說線程安全了(因?yàn)闆]有中間的三部環(huán)節(jié)，一步到位【原子性】~

原子性就是執(zhí)行某一個(gè)操作是不可分割的，

- 比如上面所說的`count++`操作，它就不是一個(gè)原子性的操作，它是分成了三個(gè)步驟的來實(shí)現(xiàn)這個(gè)操作的~
- **JDK中有atomic包提供給我們實(shí)現(xiàn)原子性操作**~

也有人將其做成了表格來分類，我們來看看：

使用這些類相關(guān)的操作也可以進(jìn)他的博客去看看：

https://blog.csdn.net/eson_15/article/details/51553338

對(duì)于可見性，Java提供了一個(gè)關(guān)鍵字：volatile給我們使用~

我們可以簡單認(rèn)為：volatile是一種輕量級(jí)的同步機(jī)制

volatile經(jīng)典總結(jié)：volatile僅僅用來保證該變量對(duì)所有線程的可見性，但不保證原子性

我們將其拆開來解釋一下：

保證該變量對(duì)所有線程的可見性

在多線程的環(huán)境下：當(dāng)這個(gè)變量修改時(shí)，所有的線程都會(huì)知道該變量被修改了，也就是所謂的“可見性”

不保證原子性

修改變量(賦值)實(shí)質(zhì)上是在JVM中分了好幾步，而在這幾步內(nèi)(從裝載變量到修改)，它是不安全的。

使用了volatile修飾的變量保證了三點(diǎn)：

一旦你完成寫入，任何訪問這個(gè)字段的線程將會(huì)得到最新的值

在你寫入前，會(huì)保證所有之前發(fā)生的事已經(jīng)發(fā)生，并且任何更新過的數(shù)據(jù)值也是可見的，因?yàn)閮?nèi)存屏障會(huì)把之前的寫入值都刷新到緩存。

volatile可以防止重排序(重排序指的就是：程序執(zhí)行的時(shí)候，CPU、編譯器可能會(huì)對(duì)執(zhí)行順序做一些調(diào)整，導(dǎo)致執(zhí)行的順序并不是從上往下的。從而出現(xiàn)了一些意想不到的效果)。而如果聲明了volatile，那么CPU、編譯器就會(huì)知道這個(gè)變量是共享的，不會(huì)被緩存在寄存器或者其他不可見的地方。

一般來說，volatile大多用于標(biāo)志位上(判斷操作),滿足下面的條件才應(yīng)該使用volatile修飾變量：

修改變量時(shí)不依賴變量的當(dāng)前值(因?yàn)関olatile是不保證原子性的)

該變量不會(huì)納入到不變性條件中(該變量是可變的)

在訪問變量的時(shí)候不需要加鎖(加鎖就沒必要使用volatile這種輕量級(jí)同步機(jī)制了)

參考資料：

http://www.cnblogs.com/Mainz/p/3556430.html

https://www.cnblogs.com/Mainz/p/3546347.html

http://www.dataguru.cn/java-865024-1-1.html

在多線程的環(huán)境下，只要我們不使用成員變量(不共享數(shù)據(jù)),那么就不會(huì)出現(xiàn)線程安全的問題了。

就用我們熟悉的Servlet來舉例子，寫了那么多的Servlet，你見過我們說要加鎖嗎？？我們所有的數(shù)據(jù)都是在方法(棧封閉)上操作的，每個(gè)線程都擁有自己的變量，互不干擾！

在方法上操作，只要我們保證不要在棧(方法)上發(fā)布對(duì)象(每個(gè)變量的作用域僅僅停留在當(dāng)前的方法上)，那么我們的線程就是安全的

在線程封閉上還有另一種方法，就是我之前寫過的：ThreadLocal就是這么簡單

使用這個(gè)類的API就可以保證每個(gè)線程自己獨(dú)占一個(gè)變量。(詳情去讀上面的文章即可)~

不可變對(duì)象一定線程安全的。

上面我們共享的變量都是可變的，正由于是可變的才會(huì)出現(xiàn)線程安全問題。如果該狀態(tài)是不可變的，那么隨便多個(gè)線程訪問都是沒有問題的！

Java提供了final修飾符給我們使用，final的身影我們可能就見得比較多了，但值得說明的是：

final僅僅是不能修改該變量的引用，但是引用里邊的數(shù)據(jù)是可以改的!

就好像下面這個(gè)HashMap，用final修飾了。但是它僅僅保證了該對(duì)象引用hashMap變量所指向是不可變的，但是hashMap內(nèi)部的數(shù)據(jù)是可變的，也就是說：可以add，remove等等操作到集合中~~~

因此，僅僅只能夠說明hashMap是一個(gè)不可變的對(duì)象引用

  final HashMap hashMap = new HashMap<>();

不可變的對(duì)象引用在使用的時(shí)候還是需要加鎖的

或者把Person也設(shè)計(jì)成是一個(gè)線程安全的類~

因?yàn)閮?nèi)部的狀態(tài)是可變的，不加鎖或者Person不是線程安全類，操作都是有危險(xiǎn)的！

要想將對(duì)象設(shè)計(jì)成不可變對(duì)象，那么要滿足下面三個(gè)條件：

對(duì)象創(chuàng)建后狀態(tài)就不能修改

對(duì)象所有的域都是final修飾的

對(duì)象是正確創(chuàng)建的(沒有this引用逸出)

String在我們學(xué)習(xí)的過程中我們就知道它是一個(gè)不可變對(duì)象，但是它沒有遵循第二點(diǎn)(對(duì)象所有的域都是final修飾的)，因?yàn)镴VM在內(nèi)部做了優(yōu)化的。但是我們?nèi)绻且约涸O(shè)計(jì)不可變對(duì)象，是需要滿足三個(gè)條件的。

很多時(shí)候我們要實(shí)現(xiàn)線程安全未必就需要自己加鎖，自己來設(shè)計(jì)。

我們可以使用JDK給我們提供的對(duì)象來完成線程安全的設(shè)計(jì)：

非常多的"工具類"供我們使用，這些在往后的學(xué)習(xí)中都會(huì)有所介紹的~~這里就不介紹了

正確使用多線程能夠提高我們應(yīng)用程序的效率，同時(shí)給我們會(huì)帶來非常多的問題，這些都是我們在使用多線程之前需要注意的地方。

無論是不變性、可見性、原子性、線程封閉、委托這些都是實(shí)現(xiàn)線程安全的一種手段。要合理地使用這些手段，我們的程序才可以更加健壯！

可以發(fā)現(xiàn)的是，上面在很多的地方說到了：鎖。但我沒有介紹它，因?yàn)槲掖蛩?strong>留在下一篇來寫，敬請(qǐng)期待~~~

書上前4章花了65頁來講解，而我只用了一篇文章來概括，這是遠(yuǎn)遠(yuǎn)不夠的，想要繼續(xù)深入的同學(xué)可以去閱讀書籍~

之前在學(xué)習(xí)操作系統(tǒng)的時(shí)候根據(jù)《計(jì)算機(jī)操作系統(tǒng)-湯小丹》這本書也做了一點(diǎn)點(diǎn)筆記，都是比較淺顯的知識(shí)點(diǎn)。或許對(duì)大家有幫助

操作系統(tǒng)第一篇【引論】

操作系統(tǒng)第二篇【進(jìn)程管理】

操作系統(tǒng)第三篇【線程】

操作系統(tǒng)第四篇【處理機(jī)調(diào)度】

操作系統(tǒng)第五篇【死鎖】

操作系統(tǒng)第六篇【存儲(chǔ)器管理】

操作系統(tǒng)第七篇【設(shè)備管理】

參考資料：

《Java核心技術(shù)卷一》

《Java并發(fā)編程實(shí)戰(zhàn)》

《計(jì)算機(jī)操作系統(tǒng)-湯小丹》

如果文章有錯(cuò)的地方歡迎指正，大家互相交流。習(xí)慣在微信看技術(shù)文章，想要獲取更多的Java資源的同學(xué)，可以關(guān)注微信公眾號(hào):Java3y。為了大家方便，剛新建了一下qq群：742919422，大家也可以去交流交流。謝謝支持了！希望能多介紹給其他有需要的朋友

文章的目錄導(dǎo)航：

https://zhongfucheng.bitcron.com/post/shou-ji/wen-zhang-dao-hang