[[360353]]

進程與線程

「進程」

進程的本質(zhì)是一個正在執(zhí)行的程序，程序運行時系統(tǒng)會創(chuàng)建一個進程，并且「給每個進程分配獨立的內(nèi)存地址空間，用來保證每個進程地址不會相互干擾」。

同時，在 CPU 對進程做時間片的切換時，保證進程切換過程中仍然要從進程切換之前運行的位置處開始執(zhí)行。所以進程通常還會包括程序計數(shù)器、堆棧指針。

相對好理解點的案例：電腦上開啟QQ就是開啟一個進程、打開IDEA就是開啟一個進程、打開瀏覽器就是開啟一個進程.....

當(dāng)我們的電腦開啟你太多的運用(QQ，微信，瀏覽器、PDF、word、IDEA等)后，電腦就很容易出現(xiàn)卡頓，甚至死機，這里最主要原因就是CPU一直不停地切換導(dǎo)致的。

下圖是單核CPU情況下，多進程之間的切換：

有了進程以后，可以讓操作系統(tǒng)從宏觀層面實現(xiàn)多應(yīng)用并發(fā)。

而并發(fā)的實現(xiàn)是通過 CPU 時間片不端切換執(zhí)行的，對于單核 CPU來說，在任意一個時刻只會有一個進程在被CPU 調(diào)度。

線程的生命周期

既然是生命周期，那么就很有可能會有階段性的或者狀態(tài)的，比如人的一生一樣：

精子和卵子結(jié)合---> 嬰兒---> 小孩--> 成年--> 中年--> 老年-->去世

線程狀態(tài)

關(guān)于線程的生命周期網(wǎng)上有不一樣的答案，有說五種也有說六種。

Java中線程確實有6種，這是有理有據(jù)的，可以看看java.lang.Thread類中有個這么一個枚舉。

public enum State { 
        NEW, 
        RUNNABLE, 
        BLOCKED,  
        WAITING,  
        TIMED_WAITING,  
        TERMINATED; 
} 

這就是Java線程對應(yīng)的狀態(tài)，組合起來就是Java中一個線程的生命周期。下面是這個枚舉的注釋：

每種狀態(tài)簡單說明：

• NEW(初始)：線程被創(chuàng)建后尚未啟動。
• RUNNABLE(運行)：包括了操作系統(tǒng)線程狀態(tài)中的Running和Ready，也就是處于此狀態(tài)的線程可能正在運行，也可能正在等待系統(tǒng)資源，如等待CPU為它分配時間片。
• BLOCKED(阻塞)：線程阻塞于鎖。
• WAITING(等待)：線程需要等待其他線程做出一些特定動作(通知或中斷)。
• TIME_WAITING(超時等待)：該狀態(tài)不同于WAITING，它可以在指定的時間內(nèi)自行返回。
• TERMINATED(終止)：該線程已經(jīng)執(zhí)行完畢。

線程生命周期

借用網(wǎng)上的這張圖，這張圖描述的很清楚了，這里就不在啰嗦。

何為線程安全?

我們經(jīng)常會聽說某個類是線程安全，某個類不是線程安全的。那么究竟什么叫做線程安全呢?

我們引用《Java Concurrency in Practice》里面的定義：

在不使用額外同步的情況下，多個線程訪問一個對象時，不論線程之間如何交替執(zhí)行或者在調(diào)用方進行任何其它的協(xié)調(diào)操作，調(diào)用這個對象的行為都能得到正確的結(jié)果，那么這個對象是線程安全的。

也可以這么理解：

多個線程訪問同一個對象時，如果不用考慮這些線程在運行時環(huán)境下的調(diào)度和交替執(zhí)行，也不需要進行額外的同步，或者在調(diào)用方進行任何其他操作，調(diào)用這個對象的行為都可以獲得正確的結(jié)果，那么這個對象就是線程安全的。或者說：一個類或者程序所提供的接口對于線程來說是原子操作或者多個線程之間的切換不會導(dǎo)致該接口的執(zhí)行結(jié)果存在二義性，也就是說我們不用考慮同步的問題。

可以簡單的理解為：“你隨便怎么調(diào)用，出了問題算我輸”。

這個定義對于類來說是十分嚴(yán)格的，即使是Java API中標(biāo)為線程安全的類也很難滿足這個要求。

比如Vector是標(biāo)記為線程安全的，但實際上并不能滿足這個條件，舉個例子：

public class Vector<E>  extends AbstractList<E>  implements List<E>, RandomAccess, Cloneable, java.io.Serializable{ 
    public synchronized E get(int index) { 
        if (index >= elementCount) 
            throw new ArrayIndexOutOfBoundsException(index); 
        return elementData(index); 
    } 
    public synchronized void removeElementAt(int index) { 
        modCount++; 
        if (index >= elementCount) { 
            throw new ArrayIndexOutOfBoundsException(index + " >= " + 
                                                     elementCount); 
        } 
        else if (index < 0) { 
            throw new ArrayIndexOutOfBoundsException(index); 
        } 
        int j = elementCount - index - 1; 
        if (j > 0) { 
            System.arraycopy(elementData, index + 1, elementData, index, j); 
        } 
        elementCount--; 
        elementData[elementCount] = null; /* to let gc do its work */ 
    } 
    //....基本上所有方法都是synchronized修飾的 
}    

來看下面一個案例：

判斷Vector中第0個元素是不是空字符，如果是空字符就將其刪除。

package com.java.tian.blog.utils; 
 
import java.util.Vector; 
 
public class SynchronizedDemo{ 
    static Vector<String> vct = new Vector<String>(); 
    public  void remove() { 
        if("".equals(vct.get(0))) { 
            vct.remove(0); 
        } 
    } 
 
    public static void main(String[] args) { 
        vct.add(""); 
        SynchronizedDemo synchronizedDemo = new SynchronizedDemo(); 
        new Thread(new Runnable() { 
            @Override 
            public void run() { 
                synchronizedDemo.remove(); 
            } 
        },"線程1").start(); 
        new Thread(new Runnable() { 
            @Override 
            public void run() { 
                synchronizedDemo.remove(); 
            } 
        },"線程2").start(); 
 
    } 
} 

上面的邏輯看起來沒有問題，實際上是有可能導(dǎo)致錯誤的：假設(shè)第0個元素是空字符，判斷的時候得到的結(jié)果是true。

兩個線程同時執(zhí)行上面的remove方法，(「極端的情況」)都「可能」get到的是""，然后都去刪除第0個元素，這個元素有可能已經(jīng)被其它線程刪除了，因此Vector不是絕對線程安全的。(上面這個案例只是做演示而已，在你的業(yè)務(wù)代碼里面這么寫的話，線程安全真的就不能靠Vector來保證了)。

通常情況下我們說的線程安全都是相對線程安全，相對線程安全只要求調(diào)用單個方法的時候不需要同步就可以得到正確的結(jié)果，但數(shù)多個方法組合調(diào)用的時候也是有可能導(dǎo)致多線程問題的。

如果想讓上面的操作執(zhí)行正確，我們需要在調(diào)用Vector方法的時候添加額外的同步操作：

package com.java.tian.blog.utils; 
 
import java.util.Vector; 
 
public class SynchronizedDemo { 
    static Vector<String> vct = new Vector<String>(); 
 
    public void remove() { 
        synchronized (vct) { 
        //synchronized (SynchronizedDemo.class) { 
            if ("".equals(vct.get(0))) { 
                vct.remove(0); 
            } 
        } 
    } 
 
    public static void main(String[] args) { 
        vct.add(""); 
        SynchronizedDemo synchronizedDemo = new SynchronizedDemo(); 
        new Thread(new Runnable() { 
            @Override 
            public void run() { 
                synchronizedDemo.remove(); 
            } 
        }, "線程1").start(); 
        new Thread(new Runnable() { 
            @Override 
            public void run() { 
                synchronizedDemo.remove(); 
            } 
        }, "線程2").start(); 
    } 
} 

根據(jù)Vector的源代碼可知：Vector的每個方法都使用了synchronized關(guān)鍵字修飾，因此鎖對象就是這個對象本身。在上面的代碼中我們嘗試獲取的也是vct對象的鎖，可以和vct對象的其它方法互斥，因此這樣做可以保證得到正確的結(jié)果。

如果Vector內(nèi)部使用的是其它鎖同步的，并封裝了鎖對象，那么我們無論如何都無法正確執(zhí)行這個“先判斷后修改”的操作。

假設(shè)被封裝的對象鎖為obj，get()和remove()方法對應(yīng)的鎖都是obj，而整個操作過程獲取的是vct的鎖，一個線程調(diào)用get()方法成功后就釋放了obj的鎖，這時這個線程只持有vct的鎖，而其它線程可以獲得obj的鎖并搶先一步刪除了第0個元素。

Java為開發(fā)者提供了很多強大的工具類，這些工具類里面有的是線程安全的，有的不是線程安全的。在這里我們列舉幾個面試常考的：

線程安全的類：Vector、Hashtable、StringBuffer

非線程安全的類：ArrayList、HashMap、StringBuilder

有人可能會反問：為什么Java不把所有的類都設(shè)計成線程安全的呢?這樣對于我們開發(fā)者來說豈不是更爽嗎?我們就不用考慮什么線程安全問題了。

事情都是具有兩面性的，獲得線程安全但是性能會有所下降，畢竟鎖的開銷是擺在那里的。線程不安全但是性能會有所提升，具體場景還得看業(yè)務(wù)更偏向于哪一個。

一個問題引發(fā)的思考：

public class SynchronizedDemo { 
 
    static int count; 
 
    public void incre() { 
        try { 
            //每個線程都睡一會，模仿業(yè)務(wù)代碼 
            Thread.sleep(100 ); 
        } catch (InterruptedException e) { 
            e.printStackTrace(); 
        } 
        count++; 
    } 
 
    public static void main(String[] args) { 
        SynchronizedDemo synchronizedDemo = new SynchronizedDemo(); 
 
        for (int i = 0; i < 1000; i++) { 
            new Thread(new Runnable() { 
                @Override 
                public void run() { 
                    synchronizedDemo.incre(); 
                } 
            }).start(); 
        } 
        try { 
            //讓主線程等待所有線程執(zhí)行完畢 
            Thread.sleep(2000L); 
        } catch (InterruptedException e) { 
            e.printStackTrace(); 
        } 
        System.out.println(count); 
    } 
} 

上面這段代碼輸出的結(jié)果是不確定的，結(jié)果是小于等于1000。

1000線程都去對count進行++操作。

對象內(nèi)存布局

對象在內(nèi)存中的存儲可以分為 3 塊區(qū)域，分別是對象頭、實例數(shù)據(jù)和對齊填充。

其中，對象頭包括兩部分內(nèi)容，一部分是對象本身的運行時數(shù)據(jù)，像 GC 分代年齡、哈希碼、鎖狀態(tài)標(biāo)識等等，官方稱之為“Mark Word”，如果忽略壓縮指針的影響，這部分?jǐn)?shù)據(jù)在 32 位和 64 位的虛擬機中分別占 32 位和 64 位。

但是對象需要存儲的運行時數(shù)據(jù)很多，32 位或者 64 位都不一定能存的下，考慮到虛擬機的空間效率，這個 Mark Word 被設(shè)計成一個非固定的數(shù)據(jù)結(jié)構(gòu)，它會根據(jù)對象的狀態(tài)復(fù)用自己的存儲空間，對象處于不同狀態(tài)的時候，對應(yīng)的 bit 表示的含義可能會不一樣，見下圖，以 32 位 Hot Spot 虛擬機為例：

從上圖中我們可以看出，如果對象處于未鎖定狀態(tài)(無鎖態(tài))，那么 Mark Word 的 25 位用于存儲對象的哈希碼，4 位用于存儲對象分代年齡，1 位固定為 0，兩位用于存儲鎖標(biāo)志位。

這個圖對于理解后面提到的輕量級鎖、偏向鎖是非常重要的，當(dāng)然我們現(xiàn)在可以先著重考慮對象處于重量級鎖狀態(tài)下的情況，也就是鎖標(biāo)志位為 10。同時我們看到，無鎖態(tài)和偏向鎖狀態(tài)下，2 位鎖標(biāo)志位都是“01”，留有 1 位表示是否可偏向，我們姑且叫它“偏向位”。

「注」：對象頭的另一部分則是類型指針，虛擬機可以通過這個指針來確認(rèn)該對象是哪個類的實例。但是我們要注意，并不是所有的虛擬機都必須以這種方式來確定對象的元數(shù)據(jù)信息。對象的訪問定位一般有句柄和直接指針兩種，如果使用句柄的話，那么對象的元數(shù)據(jù)信息可以直接包含在句柄中(當(dāng)然也包括對象實例數(shù)據(jù)的地址信息)，也就沒必要將這些元數(shù)據(jù)和實例數(shù)據(jù)存儲在一起了。至于實例數(shù)據(jù)和對齊填充，這里暫不做討論。

前面我們提到了，Java 中的每個對象都與一個 monitor 相關(guān)聯(lián)，當(dāng)鎖標(biāo)志位為 10 時，除了 2bit 的標(biāo)志位，指向的就是 monitor 對象的地址(還是以 32 位虛擬機為例)。這里我們可以翻閱一下 OpenJDK 的源碼，如果我們需要下載openJDK的源碼：

找到。這里先看一下markOpp.hpp文件。該文件的相對路徑為：

openjdk\hotspot\src\share\vm\oops 

下圖是文件中的注釋部分：

我們可以看到，其中描述了 32 位和 64 位下 Mark World 的存儲狀態(tài)。也可以看到64位下，前25位是沒有使用的。

我們也可以看到 markOop.hpp 中定義的鎖狀態(tài)枚舉，對應(yīng)我們前面提到的無鎖、偏向鎖、輕量級鎖、重量級鎖(膨脹鎖)、GC 標(biāo)記等：

enum { locked_value             = 0,//00 輕量級鎖 
       unlocked_value           = 1,//01 無鎖 
       monitor_value            = 2,//10 重量級鎖 
       marked_value             = 3,//11 GC標(biāo)記 
       biased_lock_pattern      = 5 //101 偏向鎖，1位偏向標(biāo)記和2位狀態(tài)標(biāo)記(01) 
}; 

從注釋中，我們也可以看到對其的簡要描述，后面會我們詳細(xì)解釋：

這里我們的重心還是是重量級鎖，所以我們看看源碼中 monitor 對象是如何定義的，對應(yīng)的頭文件是 objectMonitor.hpp，文件路徑為：

openjdk\hotspot\src\share\vm\runtime 

我們來簡單看一下這個 objectMonitor.hpp 的定義：

// initialize the monitor, exception the semaphore, all other fields 
// are simple integers or pointers 
ObjectMonitor() { 
  _header       = NULL; 
  _count        = 0; 
  _waiters      = 0,//等待線程數(shù) 
  _recursions   = 0;//重入次數(shù) 
  _object       = NULL; 
  _owner        = NULL;//持有鎖的線程(邏輯上，實際上除了THREAD，還可能是Lock Record) 
  _WaitSet      = NULL;//線程wait之后會進入該列表 
  _WaitSetLock  = 0 ; 
  _Responsible  = NULL ; 
  _succ         = NULL ; 
  _cxq          = NULL ;//等待獲取鎖的線程列表，和_EntryList配合使用 
  FreeNext      = NULL ; 
  _EntryList    = NULL ;//等待獲取鎖的線程列表，和_cxq配合使用 
  _SpinFreq     = 0 ; 
  _SpinClock    = 0 ; 
  OwnerIsThread = 0 ;//當(dāng)前持有者是否為THREAD類型，如果是輕量級鎖膨脹而來，還沒有enter的話， 
                     //_owner存儲的可能會是Lock Record 
  _previous_owner_tid = 0; 
} 

簡單的說，當(dāng)多個線程競爭訪問同一段同步代碼塊時，如果線程獲取到了 monitor，那么就會把 _owner 設(shè)置成當(dāng)前線程，如果是重入的話，_recursions 會加 1，如果獲取 monitor 失敗，則會進入 _cxq隊列。

鎖被釋放時，_cxq中的線程會被移動到 _EntryList中，并且喚醒_EntryList 隊首線程。當(dāng)然，選取喚醒線程有幾個不同的策略(Knob_QMode)，還是后面結(jié)合源碼解析。

「注」：_cxq和 _EntryList本質(zhì)上是ObjectWaiter 類型，它本質(zhì)上其實是一個雙向鏈表 (具有前后指針)，只是在使用的時候不一定要當(dāng)做雙向鏈表使用，比如 _cxq 是當(dāng)做單向鏈表使用的，_EntryList是當(dāng)做雙向鏈表使用的。

什么場景會導(dǎo)致線程的上下文切換?

導(dǎo)致線程上下文切換的有兩種類型：

自發(fā)性上下文切換是指線程由 Java 程序調(diào)用導(dǎo)致切出，在多線程編程中，執(zhí)行調(diào)用上圖中的方法或關(guān)鍵字，常常就會引發(fā)自發(fā)性上下文切換。

非自發(fā)性上下文切換指線程由于調(diào)度器的原因被迫切出。常見的有：線程被分配的時間片用完，虛擬機垃圾回收導(dǎo)致或者執(zhí)行優(yōu)先級的問題導(dǎo)致。

waity /notify

注意兩個隊列：

等待隊列：notifyAll/notify喚醒的就是等待隊列中的線程;

同步線程：就是競爭鎖的所有線程，等待隊列中的線程被喚醒后進入同步隊列。

sleep與wait的區(qū)別

sleep

• 讓當(dāng)前線程休眠指定時間。
• 休眠時間的準(zhǔn)確性依賴于系統(tǒng)時鐘和CPU調(diào)度機制。
• 不釋放已獲取的鎖資源，如果sleep方法在同步上下文中調(diào)用，那么其他線程是無法進入到當(dāng)前同步塊或者同步方法中的。
• 可通過調(diào)用interrupt()方法來喚醒休眠線程。
• sleep是Thread里的方法

wait

• 讓當(dāng)前線程進入等待狀態(tài)，當(dāng)別的其他線程調(diào)用notify()或者notifyAll()方法時，當(dāng)前線程進入就緒狀態(tài)
• wait方法必須在同步上下文中調(diào)用，例如：同步方法塊或者同步方法中，這也就意味著如果你想要調(diào)用wait方法，前提是必須獲取對象上的鎖資源
• 當(dāng)wait方法調(diào)用時，當(dāng)前線程將會釋放已獲取的對象鎖資源，并進入等待隊列，其他線程就可以嘗試獲取對象上的鎖資源。
• wait是Object中的方法

樂觀鎖、悲觀鎖、可重入鎖.....

作為一個Java開發(fā)多年的人來說，肯定多多少少熟悉一些鎖，或者聽過一些鎖。今天就來做一個鎖相關(guān)總結(jié)。

悲觀鎖和樂觀鎖

悲觀鎖

顧名思義，他就是很悲觀，把事情都想的最壞，是指該鎖只能被一個線程鎖持有，如果A線程獲取到鎖了，這時候線程B想獲取鎖只能排隊等待線程A釋放。

在數(shù)據(jù)庫中這樣操作：

select user_name，user_pwd from t_user for update; 

樂觀鎖

顧名思義，樂觀，人樂觀就是什么是都想得開，船到橋頭自然直。樂觀鎖就是我都覺得他們都沒有拿到鎖，只有我拿到鎖了，最后再去問問這個鎖真的是我獲取的嗎?是就把事情給干了。

典型的代表：CAS=Compare and Swap 先比較哈，資源是不是我之前看到的那個，是那我就把他換成我的。不是就算了。

在Java中java.util.concurrent.atomic包下面的原子變量就是使用了樂觀鎖的一種實現(xiàn)方式CAS實現(xiàn)。

通常都是 使用version、時間戳等來比較是否已被其他線程修改過。

使用悲觀鎖還是使用樂觀鎖?

在樂觀鎖與悲觀鎖的選擇上面，主要看下兩者的區(qū)別以及適用場景就可以了。

「響應(yīng)效率」

如果需要非常高的響應(yīng)速度，建議采用樂觀鎖方案，成功就執(zhí)行，不成功就失敗，不需要等待其他并發(fā)去釋放鎖。樂觀鎖并未真正加鎖，效率高。一旦鎖的粒度掌握不好，更新失敗的概率就會比較高，容易發(fā)生業(yè)務(wù)失敗。

「沖突頻率」

如果沖突頻率非常高，建議采用悲觀鎖，保證成功率。沖突頻率大，選擇樂觀鎖會需要多次重試才能成功，代價比較大?！钢卦嚧鷥r」

如果重試代價大，建議采用悲觀鎖。悲觀鎖依賴數(shù)據(jù)庫鎖，效率低。更新失敗的概率比較低。

樂觀鎖如果有人在你之前更新了，你的更新應(yīng)當(dāng)是被拒絕的，可以讓用戶從新操作。悲觀鎖則會等待前一個更新完成。這也是區(qū)別。

公平鎖和非公平鎖

公平鎖

顧名思義，是公平的，先來先得，F(xiàn)IFO;必須遵守排隊規(guī)則。不能僭越。多個線程按照申請鎖的順序去獲得鎖，線程會直接進入隊列去排隊，永遠(yuǎn)都是隊列的第一位才能得到鎖。

在ReentrantLock中默認(rèn)使用的非公平鎖，但是可以在構(gòu)建ReentrantLock實例時候指定為公平鎖。

ReentrantLock fairSyncLock = new ReentrantLock(true); 

假設(shè)線程 A 已經(jīng)持有了鎖，這時候線程 B 請求該鎖將會被掛起，當(dāng)線程 A 釋放鎖后，假如當(dāng)前有線程 C 也需要獲取該鎖，那么在公平鎖模式下，獲取鎖和釋放鎖的步驟為：

1. 線程A獲取鎖--->線程A釋放鎖
2. 線程B獲取鎖--->線程B釋放鎖;
3. 線程C獲取鎖--->線程釋放鎖;

「優(yōu)點」

所有的線程都能得到資源，不會餓死在隊列中。

「缺點」

吞吐量會下降很多，隊列里面除了第一個線程，其他的線程都會阻塞，CPU喚醒阻塞線程的開銷會很大。

非公平鎖

顧名思義，老子才不管你們誰先排隊的，也就是平時大家在生活中很討厭的。生活中排隊的很多，上車排隊、坐電梯排隊、超市結(jié)賬付款排隊等等。但是不是每個人都會遵守規(guī)則站著排隊，這就對站著排隊的人來說就不公平了。等搶不到后再去乖乖排隊。

多個線程去獲取鎖的時候，會直接去嘗試獲取，獲取不到，再去進入等待隊列，如果能獲取到，就直接獲取到鎖。

上面說過在ReentrantLock中默認(rèn)使用的非公平鎖，兩種方式：

ReentrantLock fairSyncLock = new ReentrantLock(false); 

或者：

ReentrantLock fairSyncLock = new ReentrantLock(); 

都可以實現(xiàn)非公平鎖。

「優(yōu)點」

可以減少CPU喚醒線程的開銷，整體的吞吐效率會高點，CPU也不必取喚醒所有線程，會減少喚起線程的數(shù)量。

「缺點」

大家可能也發(fā)現(xiàn)了，這樣可能導(dǎo)致隊列中間的線程一直獲取不到鎖或者長時間獲取不到鎖，導(dǎo)致餓死。

獨享鎖和共享鎖

獨享鎖

獨享鎖也叫排他鎖/互斥鎖，是指該鎖一次只能被一個線程鎖持有。如果線程T對數(shù)據(jù)A加上排他鎖后，則其他線程不能再對A加任何類型的鎖。獲得排他鎖的線程既能讀數(shù)據(jù)又能修改數(shù)據(jù)。JDK中的synchronized和JUC中Lock的實現(xiàn)類就是互斥鎖。

共享鎖

共享鎖是指該鎖可被多個線程所持有。如果線程T對數(shù)據(jù)A加上共享鎖后，則其他線程只能對A再加共享鎖，不能加排他鎖。獲得共享鎖的線程只能讀數(shù)據(jù)，不能修改數(shù)據(jù)。

對于ReentrantLock而言，其是獨享鎖。但是對于Lock的另一個實現(xiàn)類ReadWriteLock，其讀鎖是共享鎖，其寫鎖是獨享鎖。

1. 讀鎖的共享鎖可保證并發(fā)讀是非常高效的，讀寫，寫讀 ，寫寫的過程是互斥的。
2. 獨享鎖與共享鎖也是通過AQS來實現(xiàn)的，通過實現(xiàn)不同的方法，來實現(xiàn)獨享或者共享。

可重入鎖

若當(dāng)前線程執(zhí)行中已經(jīng)獲取了鎖，如果再次獲取該鎖時，就會獲取不到被阻塞。

public class RentrantLockDemo { 
    public synchronized void test(){ 
        System.out.println("test"); 
    } 
 
    public synchronized void test1(){ 
        System.out.println("test1"); 
        test(); 
    } 
 
    public static void main(String[] args) { 
        RentrantLockDemo rentrantLockDemo = new RentrantLockDemo(); 
        //線程1 
        new Thread(() -> rentrantLockDemo.test1()).start(); 
    } 
} 

當(dāng)一個線程執(zhí)行test1()方法的時候，需要獲取rentrantLockDemo的對象鎖，在test1方法匯總又會調(diào)用test方法，但是test()的調(diào)用是需要獲取對象鎖的。

可重入鎖也叫「遞歸鎖」，指的是同一線程外層函數(shù)獲得鎖之后，內(nèi)層遞歸函數(shù)仍然有獲取該鎖的代碼，但不受影響。

ThreadLocal設(shè)計原理

ThreadLocal名字中有個Thread表示線程，Local表示本地，我們就理解為線程本地變量了。

先看看ThreadLocal的整體：

最關(guān)心的三個公有方法：set、get、remove。

構(gòu)造方法

public ThreadLocal() { 
} 

構(gòu)造方法里沒有任何邏輯處理，就是簡單的創(chuàng)建一個實例。

set方法

源碼為：

public void set(T value) { 
    //獲取當(dāng)前線程     
    Thread t = Thread.currentThread(); 
    //這是什么鬼？     
    ThreadLocalMap map = getMap(t);         
    if (map != null)             
        map.set(this, value);        
    else 
        createMap(t, value); 
} 

先看看ThreadLocalMap是個什么東東：

ThreadLocalMap是ThreadLocal的靜態(tài)內(nèi)部類。

set方法整體為：

ThreadLocalMap構(gòu)造方法：

//這個屬性是ThreadLocal的，就是獲取hashcode(這列很有學(xué)問，但是我們的目的不是他) 
private final int threadLocalHashCode = nextHashCode(); 
private Entry[] table; 
private static final int INITIAL_CAPACITY = 16; 
//Entry是一個弱引用         
static class Entry extends WeakReference<ThreadLocal<?>> { 
    Object value; 
    Entry(ThreadLocal<?> k, Object v) { 
        super(k); 
        value = v;    
    }  
} 
 
ThreadLocalMap(ThreadLocal<?> firstKey, Object firstValue) { 
    //數(shù)組默認(rèn)大小為16 
    table = new Entry[INITIAL_CAPACITY]; 
    //len 為2的n次方，以ThreadLocal的計算的哈希值按照Entry[]取模（為了更好的散列） 
    int i = firstKey.threadLocalHashCode & (INITIAL_CAPACITY - 1); 
    table[i] = new Entry(firstKey, firstValue); 
    size = 1; 
    //設(shè)置閾值（擴容閾值） 
    setThreshold(INITIAL_CAPACITY);   
} 

然后我們看看map.set()方法中是如何處理的：

private void set(ThreadLocal<?> key, Object value) { 
Entry[] tab = table; 
         int len = tab.length; 
         //len 為2的n次方，以ThreadLocal的計算的哈希值按照Entry[]取模 
         int i = key.threadLocalHashCode & (len-1); 
         //找到ThreadLocal對應(yīng)的存儲的下標(biāo)，如果當(dāng)前槽內(nèi)Entry不為空， 
         //即當(dāng)前線程已經(jīng)有ThreadLocal已經(jīng)使用過Entry[i] 
         for (Entry e = tab[i]; 
              e != null; 
              e = tab[i = nextIndex(i, len)]) { 
             ThreadLocal<?> k = e.get(); 
              // 當(dāng)前占據(jù)該槽的就是當(dāng)前的ThreadLocal ,更新value結(jié)束 
             if (k == key) { 
                 e.value = value; 
                 return; 
             } 
             //當(dāng)前卡槽的弱引用可能會回收了，key:null value:xxxObject ， 
             //需清理Entry原來的value ，便于垃圾回收value，且將新的value 放在該槽里，結(jié)束 
             if (k == null) { 
                 replaceStaleEntry(key, value, i); 
                 return; 
             } 
         } 
        //在這之前沒有ThreadLocal使用Entry[i]，并進行值存儲 
         tab[i] = new Entry(key, value); 
         //累計Entry所占的個數(shù) 
         int sz = ++size; 
         // 清理key 為null 的Entry ，可能需要擴容，擴容長度為原來的2倍，并需要進行重新hash 
         if (!cleanSomeSlots(i, sz) && sz >= threshold){ 
             rehash(); 
         } 

從上面這個set方法，我們就大致可以把這三個進行一個關(guān)聯(lián)了:

Thread、ThreadLocal、ThreadLocalMap。

get方法

remove方法

expungeStaleEntry方法代碼里有點大，所以這里就貼了出來。

//刪除陳舊entry的核心方法 
private int expungeStaleEntry(int staleSlot) { 
    Entry[] tab = table; 
    int len = tab.length;             
    tab[staleSlot].value = null;//刪除value 
    tab[staleSlot] = null;//刪除entry 
    size--;//map的size自減 
    // 遍歷指定刪除節(jié)點，所有后續(xù)節(jié)點 
    Entry e; 
    int i; 
    for (i = nextIndex(staleSlot, len); 
         (e = tab[i]) != null; 
         i = nextIndex(i, len)) { 
        ThreadLocal<?> k = e.get(); 
        if (k == null) {//key為null,執(zhí)行刪除操作 
            e.value = null; 
            tab[i] = null; 
            size--; 
        } else {//key不為null,重新計算下標(biāo) 
            int h = k.threadLocalHashCode & (len - 1); 
            if (h != i) {//如果不在同一個位置 
                tab[i] = null;//把老位置的entry置null(刪除) 
                // 從h開始往后遍歷，一直到找到空為止，插入                          
                while (tab[h] != null){ 
                    h = nextIndex(h, len); 
                } 
                tab[h] = e;    
            } 
        } 
    } 
    return i; 
} 

本文轉(zhuǎn)載自微信公眾號「Java后端技術(shù)全棧」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系Java后端技術(shù)全棧公眾號。