多線程基礎(chǔ)必要知識(shí)點(diǎn)！看了學(xué)習(xí)多線程事半功倍

前言

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

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

回顧前面：

本文章的知識(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章　簡(jiǎn)介

  • 1.1　并發(fā)簡(jiǎn)史
  • 1.2　線程的優(yōu)勢(shì)
  • 1.2.1　發(fā)揮多處理器的強(qiáng)大能力
  • 1.2.2　建模的簡(jiǎn)單性
  • 1.2.3　異步事件的簡(jiǎn)化處理
  • 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　競(jìng)態(tài)條件
  • 2.2.2　示例：延遲初始化中的競(jìng)態(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　將同步策略文檔化

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

一、使用多線程遇到的問題

1.1線程安全問題

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

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

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

簡(jiǎ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ì)遇到~~~

1.3性能問題

使用多線程我們的目的就是為了提高應(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è)類是線程不安全的。最簡(jiǎn)單的方式：如果我們?cè)趕ervice方法上加上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)線程安全，并且性能是提高了而不是降低了~

二、對(duì)象的發(fā)布與逸出

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

發(fā)布(publish) 使對(duì)象能夠在當(dāng)前作用域之外的代碼中使用

逸出(escape) 當(dāng)某個(gè)不應(yīng)該發(fā)布的對(duì)象被發(fā)布了

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

  • 靜態(tài)域逸出
  • public修飾的get方法
  • 方法參數(shù)傳遞
  • 隱式的this

靜態(tài)域逸出：

image

public修飾get方法：

nSAMemW.png

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

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

2L0Blk6.png

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

2.1安全發(fā)布對(duì)象

上面談到了好幾種逸出的情況，我們接下來來談?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ǎn)單總結(jié)一下我們需要哪些知識(shí)點(diǎn)來解決多線程遇到的問題。

3.1簡(jiǎ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等等...)
    • ......
  • ...等等

3.2原子性和可見性

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

3.2.1原子性

在多線程中很多時(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)原子性操作~
image

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

圖片來源：https://blog.csdn.net/eson_15/article/details/51553338

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

3.2.2可見性

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

  • 我們可以簡(jiǎn)單認(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ī)制了)

參考資料：

3.3線程封閉

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

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

image

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

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

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

3.4不變性

不可變對(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<Person> 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è)條件的。

image

3.5線程安全性委托

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

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

ESSyxEd.png

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

四、最后

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

無論是不變性、可見性、原子性、線程封閉、委托這些都是實(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)?；蛟S對(duì)大家有幫助

參考資料：

  • 《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)航：

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容