作為一個(gè)三個(gè)多月沒有去工作的獨(dú)立開發(fā)者而言,今天去小米面試了一把.怎么說(shuō)呢,無(wú)論你水平如何,請(qǐng)確保在面試之前要做準(zhǔn)備,就像其中一位面試官說(shuō)的一樣,我知道你水平不錯(cuò),但是無(wú)論如何也是要準(zhǔn)備下的,不然你怎么會(huì)連這個(gè)方法也忘記了?

此刻,我突然覺得我是一個(gè)假程序員.為什么這么說(shuō)呢,作為一個(gè)從12年就開始寫代碼的程序員來(lái)說(shuō),忘記某個(gè)方法太可恥了.等趕明寫一篇文章就叫做"我是個(gè)假程序員"來(lái)談?wù)勥@些有趣的事兒.

話不多說(shuō),今天要談的主題是相對(duì)較深,較廣,但我努力的讓他看起來(lái)清晰明了.

存儲(chǔ)器層次結(jié)構(gòu)

對(duì)于開發(fā)者來(lái)說(shuō),存儲(chǔ)器的層次結(jié)構(gòu)應(yīng)該是非常熟悉的,大體如下:

這里寫圖片描述

其中寄存器,L1,L2,L3都被封裝在CPU芯片中,作為應(yīng)用開發(fā)者而言我們很少去注意和使用它.之所以引入L1,L2,L3高速寄存器,其根本是為了解決訪問運(yùn)算器和內(nèi)存速度不匹配.但緩存的引入也帶來(lái)兩個(gè)問題:

1. 緩存命中率:緩存的數(shù)據(jù)都是主存中數(shù)據(jù)的備份,如果指令所需要的數(shù)據(jù)恰好在緩存中,我們就說(shuō)緩存命中,反之,需要從主存中獲取.一個(gè)好的緩存策略應(yīng)該盡可能的提高命中率,如何提高卻是一件非常困難的事情.
2. 緩存一致性問題:我們知道緩存是主存數(shù)據(jù)的備份,但每個(gè)核心都有自己的緩存,當(dāng)緩存中的數(shù)據(jù)和內(nèi)存中的數(shù)據(jù)不一致時(shí),應(yīng)該以誰(shuí)的數(shù)據(jù)為準(zhǔn)呢,這就是所謂緩存一致性問題.

上面只是展示存儲(chǔ)器的層次結(jié)構(gòu),現(xiàn)在我們來(lái)更形象的來(lái)看一下CPU芯片與內(nèi)存之間聯(lián)系,以Intel i5雙核處理器為例:

這里寫圖片描述

通過(guò)上圖我們能明顯的看出各個(gè)緩存之間的聯(lián)系,在隨后的JVM內(nèi)存模型剖析中,你同樣會(huì)發(fā)現(xiàn)類似的結(jié)構(gòu).關(guān)于存儲(chǔ)器層次結(jié)構(gòu)到這里已經(jīng)足夠,畢竟我們不是專門做操作系統(tǒng)的,下面我們來(lái)聊聊主存,更確切的說(shuō)抽象的虛擬內(nèi)存.

虛擬內(nèi)存

談起內(nèi)存的時(shí)候,每個(gè)人的腦海中都會(huì)呈現(xiàn)出內(nèi)存條的形象,在很多時(shí)候,這種實(shí)物給我們對(duì)內(nèi)存最直觀的理解,對(duì)于非開發(fā)者這么理解是可以接受的,但是對(duì)于從事開發(fā)開發(fā)工作的工程師而言,我們還要加深一點(diǎn).

這里寫圖片描述

從硬件的角度來(lái)看,內(nèi)存就是一塊有固定容量的存儲(chǔ)體,與該硬件直接打交道的是我們的操作系統(tǒng).我們知道系統(tǒng)的進(jìn)程都是共享CPU和內(nèi)存資源的,現(xiàn)代操作系統(tǒng)為了更有效的管理內(nèi)存,提出了內(nèi)存的抽象概念,稱之為虛擬內(nèi)存.換言之,我們?cè)诓僮飨到y(tǒng)中所提到的內(nèi)存管理談的都是虛擬內(nèi)存.虛擬內(nèi)存的提出帶來(lái)幾個(gè)好處:

1. 虛擬內(nèi)存將主存看成是一個(gè)存儲(chǔ)在磁盤上的地址空間的告訴緩存.應(yīng)用在未運(yùn)行之前,只是存儲(chǔ)在磁盤上二進(jìn)制文件,運(yùn)行后,該應(yīng)用才被復(fù)制到主存中.
2. 它為每個(gè)進(jìn)程提供了一致的地址空間,簡(jiǎn)化了內(nèi)存管理機(jī)制.簡(jiǎn)單點(diǎn)來(lái)看就是每個(gè)進(jìn)程都認(rèn)為自己獨(dú)占該主存.最簡(jiǎn)單的例子就是一棟樓被分成許多個(gè)房間,每個(gè)房間都是獨(dú)立,是戶主專有,每個(gè)戶主都可以從零開始自助裝修.另外,在未征得其他戶主的同意之前,你是無(wú)法進(jìn)入其他房間的.

虛擬內(nèi)存的提出也改變了內(nèi)存訪問的方式.之前CPU訪問主存的方式如下:

這里寫圖片描述

上圖演示了CPU直接通過(guò)物理地址(假設(shè)是2)來(lái)訪問主存的過(guò)程,但如果有了虛擬內(nèi)存之后,整個(gè)訪問過(guò)程如下:

這里寫圖片描述

這里來(lái)解釋下什么是虛擬內(nèi)存地址.我們知道虛擬內(nèi)存為每個(gè)進(jìn)程提供了一個(gè)假象:每個(gè)進(jìn)程都在獨(dú)占地使用主存,每個(gè)進(jìn)程看到的內(nèi)存都是一樣的,這稱之為虛擬地址空間.舉個(gè)例子來(lái)說(shuō),比如我們內(nèi)存條是1G的,即最大地址空間$2^{{10}$,這時(shí)某個(gè)進(jìn)程需要4G的內(nèi)存,那么操作系統(tǒng)可以將其映射成更大的地址空間$2}{32}$,這個(gè)地址空間就是所謂的虛擬內(nèi)存地址.關(guān)于如何映射,有興趣的可以自行學(xué)習(xí).用一張圖來(lái)抽象的表示:

這里寫圖片描述

到現(xiàn)在我們明白原來(lái)原來(lái)我們所談操作系統(tǒng)中談的內(nèi)存其實(shí)是虛擬內(nèi)存,如果你是C語(yǔ)言開發(fā)者,那對(duì)此的感受可能更深.既然每個(gè)進(jìn)程都擁有自己的虛擬地址空間,那么它的布局是如何的呢?以Linux系統(tǒng)為例,來(lái)看一下它的進(jìn)程空間地址的布局:

這里寫圖片描述

到現(xiàn)在為止,我們終于走到了進(jìn)程這一步.我們知道,每個(gè)JVM都運(yùn)行在一個(gè)單獨(dú)的進(jìn)程當(dāng)中,和普通應(yīng)用不同,JVM相當(dāng)于一個(gè)操作系統(tǒng),它有著自己的內(nèi)存模型.下面,就切入到JVM的內(nèi)存模型中.

并發(fā)模型(線程)

如果java沒有多線程的支持,沒有JIT的存在,那么也不會(huì)有現(xiàn)在JVM內(nèi)存模型.為什么這么說(shuō)呢?首先我們從JIT說(shuō)起,JIT會(huì)追蹤程序的運(yùn)行過(guò)程,并對(duì)其中可能的地方進(jìn)行優(yōu)化,其中有一項(xiàng)優(yōu)化和處理器的亂序執(zhí)行類似,不過(guò)這里叫做指令重排.如果沒有多線程,也就不會(huì)存在所謂的臨界資源,如果這個(gè)前置條件不存在當(dāng)然也就不會(huì)存在資源競(jìng)爭(zhēng)這一說(shuō)法了.這樣一來(lái),可能Java早已經(jīng)被拋棄在歷史的長(zhǎng)河中.

盡管Java語(yǔ)言不像C語(yǔ)言能夠直接操作內(nèi)存,但是掌握J(rèn)VM內(nèi)存模型仍然非常重要.對(duì)于為什么要掌握J(rèn)VM內(nèi)存模型得先從Java的并發(fā)編程模型說(shuō)起.

在并發(fā)模型中需要處理兩個(gè)關(guān)鍵問題:線程之間如何通信以及線程之間如何同步.所謂的通信指的是線程之間如何交換消息,而同步則用于控制不同線程之間操作發(fā)生的相對(duì)順序.

從實(shí)現(xiàn)的角度來(lái)說(shuō),并發(fā)模型一般有兩種方式:基于共享內(nèi)存和基于消息傳遞.兩者實(shí)現(xiàn)的不同決定了通信和同步的行為的差異.在基于共享內(nèi)存的并發(fā)模型中,同步是顯示的,通信是隱式的;而在基于消息傳遞的并發(fā)模型中,通信是顯式的,同步是隱式的.我們來(lái)具體解釋一下.

在共享內(nèi)存的并發(fā)模型中,任何線程都可以公共內(nèi)存進(jìn)行操作,如果不加以顯示同步,那么執(zhí)行順序?qū)⑹遣豢芍?也恰是因?yàn)槟膫€(gè)線程都可以對(duì)公共內(nèi)存操作,所以通信是隱式的.而在基于消息傳遞的并發(fā)模型中,由于消息的發(fā)送一定是在接受之前,因此同步是隱式的,但是線程之間必須通過(guò)明確的發(fā)送消息來(lái)進(jìn)行通信.

在最終并發(fā)模型選擇方案上,java選擇基于共享內(nèi)存的并發(fā)模型,也就是顯式同步,隱式通信.如果在編寫程序時(shí),不處理好這兩個(gè)問題,那在多線程會(huì)出現(xiàn)各種奇怪的問題.因此,對(duì)任何Java程序員來(lái)說(shuō),熟悉JVM的內(nèi)存模型是非常重要的.

JVM內(nèi)存結(jié)構(gòu)

對(duì)于JVM內(nèi)存,主要包含兩方面:JVM內(nèi)存結(jié)構(gòu)和JVM內(nèi)存模型.兩者之間的區(qū)別在于模型是一種協(xié)議,規(guī)定對(duì)特定內(nèi)存或緩存的讀寫過(guò)程,千萬(wàn)不要弄混了.

很多人往往對(duì)JVM內(nèi)存結(jié)構(gòu)和進(jìn)程的內(nèi)存結(jié)構(gòu)感到困惑,這里我將幫助你梳理一下.

JVM本質(zhì)上也是一個(gè)程序,只不過(guò)它又有著類似操作系統(tǒng)的特性.當(dāng)一個(gè)JVM實(shí)例開始運(yùn)行時(shí),此時(shí)在Linux進(jìn)程中,其內(nèi)存布局如下:

這里寫圖片描述

JVM在進(jìn)程堆空間的基礎(chǔ)上再次進(jìn)行劃分,來(lái)簡(jiǎn)單看一下.此時(shí)的永生代本質(zhì)上就是Java程序程序的代碼區(qū)和數(shù)據(jù)區(qū),而年輕代和老年代才是Java程序真正使用的堆區(qū),也就是我們經(jīng)常掛在嘴邊的.但是此時(shí)的堆區(qū)和進(jìn)程上的堆卻又很大的區(qū)別:在調(diào)用C程序的malloc函數(shù)時(shí),會(huì)引起一次系統(tǒng)級(jí)的調(diào)用;在使用free函數(shù)釋放內(nèi)存時(shí),同樣也會(huì)引起一次系統(tǒng)級(jí)的調(diào)用,但是JVM中堆區(qū)并非如此:JVM一次性向系統(tǒng)申請(qǐng)一塊連續(xù)的內(nèi)存區(qū)域,作為Java程序的堆,當(dāng)Java程序使用new申請(qǐng)內(nèi)存時(shí),JVM會(huì)根據(jù)需要在這段內(nèi)存區(qū)域中為其分配,而不需要除非一次系統(tǒng)級(jí)別的調(diào)用.可以看出JVM其實(shí)自行實(shí)現(xiàn)了一條堆內(nèi)存的管理機(jī)制,這種管理方式有以下好處:

1. 減少系統(tǒng)級(jí)別的調(diào)用.大部分內(nèi)存申請(qǐng)和回首不需要觸發(fā)系統(tǒng)函數(shù),僅僅只在Java堆大小發(fā)生變化時(shí)才會(huì)引起系統(tǒng)函數(shù)的調(diào)用.相比系統(tǒng)級(jí)別的調(diào)用,JVM實(shí)現(xiàn)內(nèi)存管理成本更低.
2. 減少內(nèi)存泄漏情況的發(fā)生.通過(guò)JVM接管內(nèi)存管理過(guò)程,可以避免大多情況下的內(nèi)存泄漏問題.

現(xiàn)在已經(jīng)簡(jiǎn)單介紹了JVM內(nèi)存結(jié)構(gòu),希望這樣能幫助你打通上下.當(dāng)然,為了好理解,我省略了其中一些相對(duì)不重要的點(diǎn),如有興趣可以自行學(xué)習(xí).講完了JVM內(nèi)存結(jié)構(gòu),下一步該是什么呢?

JVM內(nèi)存模型

Java采用的是基于共享內(nèi)存的并發(fā)模型,使得JVM看起來(lái)非常類似現(xiàn)代多核處理器:在基于共享內(nèi)存的多核處理器體系架構(gòu)中,每個(gè)處理器都有自己的緩存,并且定期與主內(nèi)存進(jìn)行協(xié)調(diào).這里的線程同樣有自己的緩存(也叫工作內(nèi)存),此時(shí),JVM內(nèi)存模型呈現(xiàn)出如下結(jié)構(gòu):

WX20170227-191046@2x.png

上圖展示JVM的內(nèi)存模型,也稱之為JMM.對(duì)于JMM有以下規(guī)定:

1. 所有的變量都存儲(chǔ)在主內(nèi)存(Main Memory)
2. 每個(gè)線程也有用自己的工作內(nèi)存(Work Memory)
3. 工作內(nèi)存中的變量是主內(nèi)存變量的拷貝,線程不能直接讀寫主內(nèi)存的變量,而只能操作自己工作內(nèi)存中的變量
4. 線程間不共享工作內(nèi)存,如果線程間需要通信必須借助主內(nèi)存來(lái)完成

共享變量所在的內(nèi)存區(qū)域也就是共享內(nèi)存,也稱之為堆內(nèi)存,該區(qū)域中的變量都可能被共享,即被多線程訪問.說(shuō)的再通俗點(diǎn)就是在java當(dāng)中,堆內(nèi)存是在線程間共享的,而局部變量,形參和異常程序參數(shù)不在堆內(nèi)存,因此就不存在多線程共享的情況.

與JMM規(guī)定相對(duì)應(yīng),我們定義了以下四個(gè)原子性操作來(lái)實(shí)現(xiàn)變量從主內(nèi)存拷貝到工作內(nèi)存的過(guò)程:

1. read:讀取主內(nèi)存的變量,并將其傳送到工作內(nèi)存
2. load:把read操作從主內(nèi)存得到的變量值放入到工作內(nèi)存的拷貝中
3. store:把工作內(nèi)存中的一個(gè)變量值傳送到主內(nèi)存當(dāng)中,以便用于后面的write操作
4. write:把store操作從工作內(nèi)存中得到的變量的值放入主內(nèi)存的變量中.

可以看出,從主內(nèi)存到工作內(nèi)存的過(guò)程其實(shí)是要經(jīng)過(guò)read和load兩個(gè)操作的,反之需要經(jīng)過(guò)store和write兩個(gè)操作.

現(xiàn)在我們來(lái)看一段代碼,并用結(jié)合上文談?wù)勏露嗑€程安全問題:

public class ThreadTest {


    public static void main(String[] args) throws InterruptedException {
        ShareVar ins = new ShareVar();
        List<Thread> threadList = new ArrayList<>();

        for (int i = 0; i < 10; i++) {
            Thread thread;
            if (i % 2 == 0) {
                thread = new Thread(new AddThread(ins));

            } else {
                thread = new Thread(new SubThread(ins));

            }

            thread.start();
            threadList.add(thread);

        }

        for (Thread thread : threadList) {
            thread.join();
        }

        System.out.println(Thread.currentThread().getId() + "   " + ins.getCount());


    }


}

class ShareVar {
    private int count;

    public void add() {
        try {
            Thread.sleep(100);//此處為了更好的體現(xiàn)多線程安全問題
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        count++;


    }

    public void sub() {
        count--;
    }

    public int getCount() {
        return count;
    }
}

class AddThread implements Runnable {
    private ShareVar shareVar;

    public AddThread(ShareVar shareVar) {
        this.shareVar = shareVar;
    }

    @Override
    public void run() {
        shareVar.add();
    }
}

class SubThread implements Runnable {
    private ShareVar shareVar;

    public SubThread(ShareVar shareVar) {
        this.shareVar = shareVar;
    }

    @Override
    public void run() {
        shareVar.sub();
    }
}

理想情況下,最后應(yīng)該輸出0,但是多次運(yùn)行你會(huì)先可能輸出-1或者-2等.為什么呢?
在創(chuàng)建的這10個(gè)線程中,每個(gè)線程都有自己工作內(nèi)存,而這些線程又共享了ShareVar對(duì)象的count變量,當(dāng)線程啟動(dòng)時(shí),會(huì)經(jīng)過(guò)read-load操作從主內(nèi)存中拷貝該變量至自己的工作內(nèi)存中,隨后每個(gè)線程會(huì)在自己的工作內(nèi)存中操作該變量副本,最后會(huì)將該副本重新寫會(huì)到主內(nèi)存,替換原先變量的值.但在多個(gè)線程中,但由于線程間無(wú)法直接通信,這就導(dǎo)致變量的變化不能及時(shí)的反應(yīng)在線程當(dāng)中,這種細(xì)微的時(shí)間差最終導(dǎo)致每個(gè)線程當(dāng)前操作的變量值未必是最新的,這就是所謂的內(nèi)存不可見性.

現(xiàn)在我想你已經(jīng)完全明白了多線程安全問題的由來(lái).那該怎么解決呢?最簡(jiǎn)單的方法就是讓多個(gè)線程對(duì)共享對(duì)象的讀寫操作編程串行,也就是同一時(shí)刻只允許一個(gè)線程對(duì)共享對(duì)象進(jìn)行操作.我們將這種機(jī)制成為鎖機(jī)制,java中規(guī)定每個(gè)對(duì)象都有一把鎖,稱之為監(jiān)視器(monitor),有人也叫作對(duì)象鎖,同一時(shí)刻,該對(duì)象鎖只能服務(wù)一個(gè)線程.

有了鎖對(duì)象之后,它是怎么生效的呢?為此JMM中又定義了兩個(gè)原子操作:

1. lock:將主內(nèi)存的變量標(biāo)識(shí)為一條線程獨(dú)占狀態(tài)
2. unlock:解除主內(nèi)存中變量的線程獨(dú)占狀態(tài)

在鎖對(duì)象和這兩個(gè)原子操作共同作用下而成的鎖機(jī)制就可以實(shí)現(xiàn)同步了,體現(xiàn)在語(yǔ)言層面就是synchronized關(guān)鍵字.上面我們也說(shuō)道Java采用的是基于共享內(nèi)存的并發(fā)模型,該模型典型的特征是要顯式同步,也就是說(shuō)在要人為的使用synchronized關(guān)鍵字來(lái)做同步.現(xiàn)在我們來(lái)改進(jìn)上面的代碼,只需要為add()和sub()方法添加syhcronized關(guān)鍵字即可,但在這之前,先來(lái)看看這兩個(gè)方法對(duì)應(yīng)的字節(jié)碼文件:

  public void add();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=2, args_size=1
         0: ldc2_w        #2                  // long 100l
         3: invokestatic  #4                  // Method java/lang/Thread.sleep:(J)V
         6: goto          14
         9: astore_1
        10: aload_1
        11: invokevirtual #6                  // Method java/lang/InterruptedException.printStackTrace:()V
        14: aload_0
        15: dup
        16: getfield      #7                  // Field count:I
        19: iconst_1
        20: iadd
        21: putfield      #7                  // Field count:I
        24: return

  public void sub();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=1, args_size=1
         0: aload_0
         1: dup
         2: getfield      #7                  // Field count:I
         5: iconst_1
         6: isub
         7: putfield      #7                  // Field count:I
        10: return
      LineNumberTable:
        line 18: 0
        line 19: 10

現(xiàn)在我們使用synchronized來(lái)讓著兩個(gè)方法變得安全起來(lái):

class ShareVar {
    private int count;

    public synchronized void add() {
        try {
            Thread.sleep(100);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        count++;


    }

    public synchronized void sub() {
        count--;
    }

    public int getCount() {
        return count;
    }
}

此時(shí)這段代碼在多線程中就會(huì)表現(xiàn)良好.再來(lái)看看它的字節(jié)碼文件發(fā)生了什么變化:

  public synchronized void add();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_SYNCHRONIZED
    Code:
      stack=3, locals=2, args_size=1
         0: ldc2_w        #2                  // long 100l
         3: invokestatic  #4                  // Method java/lang/Thread.sleep:(J)V
         6: goto          14
         9: astore_1
        10: aload_1
        11: invokevirtual #6                  // Method java/lang/InterruptedException.printStackTrace:()V
        14: aload_0
        15: dup
        16: getfield      #7                  // Field count:I
        19: iconst_1
        20: iadd
        21: putfield      #7                  // Field count:I
        24: return
   

  public synchronized void sub();
    descriptor: ()V
    flags: ACC_PUBLIC, ACC_SYNCHRONIZED
    Code:
      stack=3, locals=1, args_size=1
         0: aload_0
         1: dup
         2: getfield      #7                  // Field count:I
         5: iconst_1
         6: isub
         7: putfield      #7                  // Field count:I
        10: return
      LineNumberTable:
        line 18: 0
        line 19: 10

通過(guò)字節(jié)碼不難看出最大的變化在于方法的flags中增加了ACC_SYNCHRONIZED標(biāo)識(shí),虛擬機(jī)在遇到該標(biāo)識(shí)時(shí),會(huì)隱式的為方法添加monitorenter和monitorexit指令,這兩個(gè)指令就是在JMM的lock和unlock操作上實(shí)現(xiàn)的.

其中monitorenter指令會(huì)獲取對(duì)象的占有權(quán),此時(shí)有以下三種可能:

1. 如果該對(duì)象的monitor的值0,則該線程進(jìn)入該monitor,并將其值標(biāo)為1,表明對(duì)象被該線程獨(dú)占.
2. 同一個(gè)線程,如果之前已經(jīng)占有該對(duì)象了,當(dāng)再次進(jìn)入時(shí),需將該對(duì)象的monitor的值加1.
3. 如果該對(duì)象的monitor值不為0,表明該對(duì)象被其他線程獨(dú)占了,此時(shí)該線程進(jìn)入阻塞狀態(tài),等到該對(duì)象的monitor的值為0時(shí),在嘗試獲取該對(duì)象.

而monitorexit的指令則是已占有該對(duì)象的線程在離開時(shí),將monitor的值減1,表明該線程已經(jīng)不再獨(dú)占該對(duì)象.

用synchronized修飾的方法叫做同步方法,除了這種方式之外,還可以使用同步代碼塊的形式:

package com.cd.app;

class ShareVar {
    private int count;

    public void add() {
        synchronized (this) {
            try {
                Thread.sleep(100);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            count++;
        }


    }

    public void sub() {
        synchronized (this) {
            count--;
        }

    }

    public int getCount() {
        return count;
    }
}

接下來(lái)同樣是看一下他的字節(jié)碼,主要看add()和sub()方法:

 public void add();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=3, args_size=1
         0: aload_0
         1: dup
         2: astore_1
         3: monitorenter
         4: aload_0
         5: dup
         6: getfield      #2                  // Field count:I
         9: iconst_1
        10: iadd
        11: putfield      #2                  // Field count:I
        14: aload_1
        15: monitorexit
        16: goto          24
        19: astore_2
        20: aload_1
        21: monitorexit
        22: aload_2
        23: athrow
        24: return



public void sub();
    descriptor: ()V
    flags: ACC_PUBLIC
    Code:
      stack=3, locals=3, args_size=1
         0: aload_0
         1: dup
         2: astore_1
         3: monitorenter
         4: aload_0
         5: dup
         6: getfield      #2                  // Field count:I
         9: iconst_1
        10: isub
        11: putfield      #2                  // Field count:I
        14: aload_1
        15: monitorexit
        16: goto          24
        19: astore_2
        20: aload_1
        21: monitorexit
        22: aload_2
        23: athrow
        24: return

同步代碼塊和同步方法的實(shí)現(xiàn)原理是一致的,都是通過(guò)monitorenter/monitorexit指令,唯一的區(qū)別在于同步代碼塊中monitorenter/monitorexit是顯式的加載字節(jié)碼文件當(dāng)中的.

上面我們通過(guò)synchronized解決了內(nèi)存可見性問題,另外也可以認(rèn)為凡是被synchronized修飾的方法或代碼塊都是原子性的,即一個(gè)變量從主內(nèi)存到工作內(nèi)存,再?gòu)墓ぷ鲀?nèi)存到主內(nèi)存這個(gè)過(guò)程是不可分割的.

正如我們?cè)?a target="_blank" rel="nofollow"> 談亂序執(zhí)行和內(nèi)存屏障所提到的,javac編譯器和JVM為了提高性能會(huì)通過(guò)指令重排的方式來(lái)企圖提高性能,但是在某些情況下我們同樣需要阻止這過(guò)程,由于synchronized關(guān)鍵字保證了持有同一個(gè)鎖的的兩個(gè)同步方法/同步塊只能串行進(jìn)入,因此無(wú)形之中也就相當(dāng)阻止了指令重排.

總結(jié)

希望這么從下往上,再?gòu)纳贤碌慕忉屇茏尭魑煌瑢W(xué)對(duì)JVM內(nèi)存模型以及多線程安全問題有個(gè)更通透的理解.好了,今天就到這,歡迎關(guān)注訂閱"江湖人稱小白哥"