java開發兩年，這些線程知識你都不知道，你怎麼漲薪？

時間 2021-01-07

標籤 java 面試編程緩存安全多線程併發 app 框架 jvm 欄目 Java 简体版

原文原文鏈接

前言

什麼是線程：程序中負責執行的哪一個東東就叫作線程（執行路線，進程內部的執行序列），或者說是進程的子任務。java

Java中實現多線程有幾種方法

繼承Thread類；
實現Runnable接口；
實現Callable接口經過FutureTask包裝器來建立Thread線程；
使用ExecutorService、Callable、Future實現有返回結果的多線程（也就是使用了ExecutorService來管理前面的三種方式）。面試

如何中止一個正在運行的線程

使用退出標誌，使線程正常退出，也就是當run方法完成後線程終止。
使用stop方法強行終止，可是不推薦這個方法，由於stop和suspend及resume同樣都是過時做廢的方法。
使用interrupt方法中斷線程。

class MyThread extends Thread {
    volatile boolean stop = false;

    public void run() {
        while (!stop) {
            System.out.println(getName() + " is running");
            try {
                sleep(1000);
            } catch (InterruptedException e) {
                System.out.println("week up from blcok...");
                stop = true; // 在異常處理代碼中修改共享變量的狀態
            }
        }
        System.out.println(getName() + " is exiting...");
    }
}

class InterruptThreadDemo3 {
    public static void main(String[] args) throws InterruptedException {
        MyThread m1 = new MyThread();
        System.out.println("Starting thread...");
        m1.start();
        Thread.sleep(3000);
        System.out.println("Interrupt thread...: " + m1.getName());
        m1.stop = true; // 設置共享變量爲true
        m1.interrupt(); // 阻塞時退出阻塞狀態
        Thread.sleep(3000); // 主線程休眠3秒以便觀察線程m1的中斷狀況
        System.out.println("Stopping application...");
    }
}

notify()和notifyAll()有什麼區別？

notify可能會致使死鎖，而notifyAll則不會編程

任什麼時候候只有一個線程能夠得到鎖，也就是說只有一個線程能夠運行synchronized 中的代碼緩存

使用notifyall,能夠喚醒
全部處於wait狀態的線程，使其從新進入鎖的爭奪隊列中，而notify只能喚醒一個。安全

wait() 應配合while循環使用，不該使用if，務必在wait()調用先後都檢查條件，若是不知足，必須調用notify()喚醒另外的線程來處理，本身繼續wait()直至條件知足再往下執行。多線程

notify() 是對notifyAll()的一個優化，但它有很精確的應用場景，而且要求正確使用。否則可能致使死鎖。正確的場景應該是 WaitSet中等待的是相同的條件，喚醒任一個都能正確處理接下來的事項，若是喚醒的線程沒法正確處理，務必確保繼續notify()下一個線程，而且自身須要從新回到WaitSet中.併發

sleep()和wait() 有什麼區別？

對於sleep()方法，咱們首先要知道該方法是屬於Thread類中的。而wait()方法，則是屬於Object類中的。app

sleep()方法致使了程序暫停執行指定的時間，讓出cpu該其餘線程，可是他的監控狀態依然保持者，當指定的時間到了又會自動恢復運行狀態。在調用sleep()方法的過程當中，線程不會釋放對象鎖。框架

當調用wait()方法的時候，線程會放棄對象鎖，進入等待此對象的等待鎖定池，只有針對此對象調用notify()方法後本線程才進入對象鎖定池準備，獲取對象鎖進入運行狀態。jvm

volatile 是什麼?能夠保證有序性嗎?

一旦一個共享變量（類的成員變量、類的靜態成員變量）被volatile修飾以後，那麼就具有了兩層語義：

1）保證了不一樣線程對這個變量進行操做時的可見性，即一個線程修改了某個變量的值，這新值對其餘線程來講是當即可見的,volatile關鍵字會強制將修改的值當即寫入主存。

2）禁止進行指令重排序。

volatile 不是原子性操做

什麼叫保證部分有序性?

當程序執行到volatile變量的讀操做或者寫操做時，在其前面的操做的更改確定所有已經進行，且結果已經對後面的操做可見；在其後面的操做確定尚未進行；

x = 2;        //語句1
y = 0;        //語句2
flag = true;  //語句3
x = 4;         //語句4
y = -1;       //語句5

因爲flag變量爲volatile變量，那麼在進行指令重排序的過程的時候，不會將語句3放到語句一、語句2前面，也不會講語句3放到語句四、語句5後面。可是要注意語句1和語句2的順序、語句4和語句5的順序是不做任何保證的。

使用 Volatile 通常用於狀態標記量和單例模式的雙檢鎖

Thread 類中的start() 和 run() 方法有什麼區別？

start()方法被用來啓動新建立的線程，並且start()內部調用了run()方法，這和直接調用run()方法的效果不同。當你調用run()方法的時候，只會是在原來的線程中調用，沒有新的線程啓動，start()方法纔會啓動新線程。

爲何wait, notify 和 notifyAll這些方法不在thread類裏面？

明顯的緣由是JAVA提供的鎖是對象級的而不是線程級的，每一個對象都有鎖，經過線程得到。若是線程須要等待某些鎖那麼調用對象中的wait()方法就有意義了。若是wait()方法定義在Thread類中，線程正在等待的是哪一個鎖就不明顯了。簡單的說，因爲wait，notify和notifyAll都是鎖級別的操做，因此把他們定義在Object類中由於鎖屬於對象。

爲何wait和notify方法要在同步塊中調用？

只有在調用線程擁有某個對象的獨佔鎖時，纔可以調用該對象的wait(),notify()和notifyAll()方法。
若是你不這麼作，你的代碼會拋出IllegalMonitorStateException異常。
還有一個緣由是爲了不wait和notify之間產生競態條件。

wait()方法強制當前線程釋放對象鎖。這意味着在調用某對象的wait()方法以前，當前線程必須已經得到該對象的鎖。所以，線程必須在某個對象的同步方法或同步代碼塊中才能調用該對象的wait()方法。

在調用對象的notify()和notifyAll()方法以前，調用線程必須已經獲得該對象的鎖。所以，必須在某個對象的同步方法或同步代碼塊中才能調用該對象的notify()或notifyAll()方法。

調用wait()方法的緣由一般是，調用線程但願某個特殊的狀態(或變量)被設置以後再繼續執行。調用notify()或notifyAll()方法的緣由一般是，調用線程但願告訴其餘等待中的線程:「特殊狀態已經被設置」。這個狀態做爲線程間通訊的通道，它必須是一個可變的共享狀態(或變量)。

Java中interrupted 和 isInterruptedd方法的區別？

interrupted() 和 isInterrupted()的主要區別是前者會將中斷狀態清除然後者不會。Java多線程的中斷機制是用內部標識來實現的，調用Thread.interrupt()來中斷一個線程就會設置中斷標識爲true。當中斷線程調用靜態方法Thread.interrupted()來檢查中斷狀態時，中斷狀態會被清零。而非靜態方法isInterrupted()用來查詢其它線程的中斷狀態且不會改變中斷狀態標識。簡單的說就是任何拋出InterruptedException異常的方法都會將中斷狀態清零。不管如何，一個線程的中斷狀態有有可能被其它線程調用中斷來改變。

Java中synchronized 和 ReentrantLock 有什麼不一樣？

類似點：

這兩種同步方式有不少類似之處，它們都是加鎖方式同步，並且都是阻塞式的同步，也就是說當若是一個線程得到了對象鎖，進入了同步塊，其餘訪問該同步塊的線程都必須阻塞在同步塊外面等待，而進行線程阻塞和喚醒的代價是比較高的.

區別：

這兩種方式最大區別就是對於Synchronized來講，它是java語言的關鍵字，是原生語法層面的互斥，須要jvm實現。而ReentrantLock它是JDK 1.5以後提供的API層面的互斥鎖，須要lock()和unlock()方法配合try/finally語句塊來完成。

Synchronized進過編譯，會在同步塊的先後分別造成monitorenter和monitorexit這個兩個字節碼指令。在執行monitorenter指令時，首先要嘗試獲取對象鎖。若是這個對象沒被鎖定，或者當前線程已經擁有了那個對象鎖，把鎖的計算器加1，相應的，在執行monitorexit指令時會將鎖計算器就減1，當計算器爲0時，鎖就被釋放了。若是獲取對象鎖失敗，那當前線程就要阻塞，直到對象鎖被另外一個線程釋放爲止。

因爲ReentrantLock是java.util.concurrent包下提供的一套互斥鎖，相比Synchronized，ReentrantLock類提供了一些高級功能，主要有如下3項：

1.等待可中斷，持有鎖的線程長期不釋放的時候，正在等待的線程能夠選擇放棄等待，這至關於Synchronized來講能夠避免出現死鎖的狀況。

2.公平鎖，多個線程等待同一個鎖時，必須按照申請鎖的時間順序得到鎖，Synchronized鎖非公平鎖，ReentrantLock默認的構造函數是建立的非公平鎖，能夠經過參數true設爲公平鎖，但公平鎖表現的性能不是很好。

3.鎖綁定多個條件，一個ReentrantLock對象能夠同時綁定對個對象。

有三個線程T1,T2,T3,如何保證順序執行？

在多線程中有多種方法讓線程按特定順序執行，你能夠用線程類的join()方法在一個線程中啓動另外一個線程，另一個線程完成該線程繼續執行。爲了確保三個線程的順序你應該先啓動最後一個(T3調用T2，T2調用T1)，這樣T1就會先完成而T3最後完成。

實際上先啓動三個線程中哪個都行，
由於在每一個線程的run方法中用join方法限定了三個線程的執行順序。

public class JoinTest2 {

    // 1.如今有T一、T二、T3三個線程，你怎樣保證T2在T1執行完後執行，T3在T2執行完後執行

    public static void main(String[] args) {

        final Thread t1 = new Thread(new Runnable() {

            @Override
            public void run() {
                System.out.println("t1");
            }
        });
        final Thread t2 = new Thread(new Runnable() {

            @Override
            public void run() {
                try {
                    // 引用t1線程，等待t1線程執行完
                    t1.join();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("t2");
            }
        });
        Thread t3 = new Thread(new Runnable() {

            @Override
            public void run() {
                try {
                    // 引用t2線程，等待t2線程執行完
                    t2.join();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                System.out.println("t3");
            }
        });
        t3.start();//這裏三個線程的啓動順序能夠任意，你們能夠試下！
        t2.start();
        t1.start();
    }
}

SynchronizedMap和ConcurrentHashMap有什麼區別？**

SynchronizedMap()和Hashtable同樣，實現上在調用map全部方法時，都對整個map進行同步。而ConcurrentHashMap的實現卻更加精細，它對map中的全部桶加了鎖。因此，只要有一個線程訪問map，其餘線程就沒法進入map，而若是一個線程在訪問ConcurrentHashMap某個桶時，其餘線程，仍然能夠對map執行某些操做。

因此，ConcurrentHashMap在性能以及安全性方面，明顯比Collections.synchronizedMap()更加有優點。同時，同步操做精確控制到桶，這樣，即便在遍歷map時，若是其餘線程試圖對map進行數據修改，也不會拋出ConcurrentModificationException。

什麼是線程安全

線程安全就是說多線程訪問同一代碼，不會產生不肯定的結果。

在多線程環境中，當各線程不共享數據的時候，即都是私有（private）成員，那麼必定是線程安全的。但這種狀況並很少見，在多數狀況下須要共享數據，這時就須要進行適當的同步控制了。

線程安全通常都涉及到synchronized，就是一段代碼同時只能有一個線程來操做否則中間過程可能會產生不可預製的結果。

若是你的代碼所在的進程中有多個線程在同時運行，而這些線程可能會同時運行這段代碼。若是每次運行結果和單線程運行的結果是同樣的，並且其餘的變量的值也和預期的是同樣的，就是線程安全的。

Thread類中的yield方法有什麼做用？

Yield方法能夠暫停當前正在執行的線程對象，讓其它有相同優先級的線程執行。它是一個靜態方法並且只保證當前線程放棄CPU佔用而不能保證使其它線程必定能佔用CPU，執行yield()的線程有可能在進入到暫停狀態後立刻又被執行。

Java線程池中submit() 和 execute()方法有什麼區別？

兩個方法均可以向線程池提交任務，execute()方法的返回類型是void，它定義在Executor接口中, 而submit()方法能夠返回持有計算結果的Future對象，它定義在ExecutorService接口中，它擴展了Executor接口，其它線程池類像ThreadPoolExecutor和ScheduledThreadPoolExecutor都有這些方法。

說一說本身對於 synchronized 關鍵字的瞭解

synchronized關鍵字解決的是多個線程之間訪問資源的同步性，synchronized關鍵字能夠保證被它修飾的方法或者代碼塊在任意時刻只能有一個線程執行。
另外，在 Java 早期版本中，synchronized屬於重量級鎖，效率低下，由於監視器鎖（monitor）是依賴於底層的操做系統的 Mutex Lock 來實現的，Java 的線程是映射到操做系統的原生線程之上的。若是要掛起或者喚醒一個線程，都須要操做系統幫忙完成，而操做系統實現線程之間的切換時須要從用戶態轉換到內核態，這個狀態之間的轉換須要相對比較長的時間，時間成本相對較高，這也是爲何早期的 synchronized 效率低的緣由。慶幸的是在 Java 6 以後 Java 官方對從 JVM 層面對synchronized 較大優化，因此如今的 synchronized 鎖效率也優化得很不錯了。JDK1.6對鎖的實現引入了大量的優化，如自旋鎖、適應性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術來減小鎖操做的開銷。

說說本身是怎麼使用 synchronized 關鍵字，在項目中用到了嗎synchronized關鍵字最主要的三種使用方式：

修飾實例方法: 做用於當前對象實例加鎖，進入同步代碼前要得到當前對象實例的鎖
修飾靜態方法: 也就是給當前類加鎖，會做用於類的全部對象實例，由於靜態成員不屬於任何一個實例對象，是類成員（ static 代表這是該類的一個靜態資源，無論new了多少個對象，只有一份）。因此若是一個線程A調用一個實例對象的非靜態 synchronized 方法，而線程B須要調用這個實例對象所屬類的靜態 synchronized 方法，是容許的，不會發生互斥現象，由於訪問靜態 synchronized 方法佔用的鎖是當前類的鎖，而訪問非靜態 synchronized 方法佔用的鎖是當前實例對象鎖。
修飾代碼塊: 指定加鎖對象，對給定對象加鎖，進入同步代碼庫前要得到給定對象的鎖。
總結： synchronized 關鍵字加到 static 靜態方法和 synchronized(class)代碼塊上都是是給 Class 類上鎖。synchronized 關鍵字加到實例方法上是給對象實例上鎖。儘可能不要使用 synchronized(String a) 由於JVM中，字符串常量池具備緩存功能！

什麼是線程安全？Vector是一個線程安全類嗎？

若是你的代碼所在的進程中有多個線程在同時運行，而這些線程可能會同時運行這段代碼。若是每次運行結果和單線程運行的結果是同樣的，並且其餘的變量的值也和預期的是同樣的，就是線程安全的。一個線程安全的計數器類的同一個實例對象在被多個線程使用的狀況下也不會出現計算失誤。很顯然你能夠將集合類分成兩組，線程安全和非線程安全的。Vector 是用同步方法來實現線程安全的, 而和它類似的ArrayList不是線程安全的。

volatile關鍵字的做用？

一旦一個共享變量（類的成員變量、類的靜態成員變量）被volatile修飾以後，那麼就具有了兩層語義：

保證了不一樣線程對這個變量進行操做時的可見性，即一個線程修改了某個變量的值，這新值對其餘線程來講是當即可見的。
禁止進行指令重排序。
volatile本質是在告訴jvm當前變量在寄存器（工做內存）中的值是不肯定的，須要從主存中讀取；synchronized則是鎖定當前變量，只有當前線程能夠訪問該變量，其餘線程被阻塞住。
volatile僅能使用在變量級別；synchronized則可使用在變量、方法、和類級別的。
volatile僅能實現變量的修改可見性，並不能保證原子性；synchronized則能夠保證變量的修改可見性和原子性。
volatile不會形成線程的阻塞；synchronized可能會形成線程的阻塞。

volatile標記的變量不會被編譯器優化；synchronized標記的變量能夠被編譯器優化。

經常使用的線程池有哪些？

newSingleThreadExecutor：建立一個單線程的線程池，此線程池保證全部任務的執行順序按照任務的提交順序執行。
newFixedThreadPool：建立固定大小的線程池，每次提交一個任務就建立一個線程，直到線程達到線程池的最大大小。
newCachedThreadPool：建立一個可緩存的線程池，此線程池不會對線程池大小作限制，線程池大小徹底依賴於操做系統（或者說JVM）可以建立的最大線程大小。
newScheduledThreadPool：建立一個大小無限的線程池，此線程池支持定時以及週期性執行任務的需求。
newSingleThreadExecutor：建立一個單線程的線程池。此線程池支持定時以及週期性執行任務的需求。

簡述一下你對線程池的理解

（若是問到了這樣的問題，能夠展開的說一下線程池如何用、線程池的好處、線程池的啓動策略）合理利用線程池可以帶來三個好處。

第一：下降資源消耗。經過重複利用已建立的線程下降線程建立和銷燬形成的消耗。

第二：提升響應速度。當任務到達時，任務能夠不須要等到線程建立就能當即執行。

第三：提升線程的可管理性。線程是稀缺資源，若是無限制的建立，不只會消耗系統資源，還會下降系統的穩定性，使用線程池能夠進行統一的分配，調優和監控。

Java程序是如何執行的

咱們平常的工做中都使用開發工具（IntelliJ IDEA 或 Eclipse 等）能夠很方便的調試程序，或者是經過打包工具把項目打包成 jar 包或者 war 包，放入 Tomcat 等 Web 容器中就能夠正常運行了，但你有沒有想過 Java 程序內部是如何執行的？其實不管是在開發工具中運行仍是在 Tomcat 中運行，Java 程序的執行流程基本都是相同的，它的執行流程以下：

先把 Java 代碼編譯成字節碼，也就是把 .java 類型的文件編譯成 .class 類型的文件。這個過程的大體執行流程：Java 源代碼 -> 詞法分析器 -> 語法分析器 -> 語義分析器 -> 字符碼生成器 -> 最終生成字節碼，其中任何一個節點執行失敗就會形成編譯失敗；
把 class 文件放置到 Java 虛擬機，這個虛擬機一般指的是 Oracle 官方自帶的 Hotspot JVM；
Java 虛擬機使用類加載器（Class Loader）裝載 class 文件；
類加載完成以後，會進行字節碼效驗，字節碼效驗經過以後 JVM 解釋器會把字節碼翻譯成機器碼交由操做系統執行。但不是全部代碼都是解釋執行的，JVM 對此作了優化，好比，以 Hotspot 虛擬機來講，它自己提供了 JIT（Just In Time）也就是咱們一般所說的動態編譯器，它可以在運行時將熱點代碼編譯爲機器碼，這個時候字節碼就變成了編譯執行。

說一說本身對於 synchronized 關鍵字的瞭解

synchronized關鍵字解決的是多個線程之間訪問資源的同步性，synchronized關鍵字能夠保證被它修飾的方法或者代碼塊在任意時刻只能有一個線程執行。

另外，在 Java 早期版本中，synchronized屬於重量級鎖，效率低下，由於監視器鎖（monitor）是依賴於底層的操做系統的 Mutex Lock 來實現的，Java 的線程是映射到操做系統的原生線程之上的。若是要掛起或者喚醒一個線程，都須要操做系統幫忙完成，而操做系統實現線程之間的切換時須要從用戶態轉換到內核態，這個狀態之間的轉換須要相對比較長的時間，時間成本相對較高，這也是爲何早期的 synchronized 效率低的緣由。慶幸的是在 Java 6 以後 Java 官方對從 JVM 層面對synchronized 較大優化，因此如今的 synchronized 鎖效率也優化得很不錯了。JDK1.6對鎖的實現引入了大量的優化，如自旋鎖、適應性自旋鎖、鎖消除、鎖粗化、偏向鎖、輕量級鎖等技術來減小鎖操做的開銷。

說說本身是怎麼使用 synchronized 關鍵字，在項目中用到了嗎

synchronized關鍵字最主要的三種使用方式：

修飾實例方法，做用於當前對象實例加鎖，進入同步代碼前要得到當前對象實例的鎖
修飾靜態方法，做用於當前類對象加鎖，進入同步代碼前要得到當前類對象的鎖。也就是給當前類加鎖，會做用於類的全部對象實例，由於靜態成員不屬於任何一個實例對象，是類成員（ static 代表這是該類的一個靜態資源，無論new了多少個對象，只有一份，因此對該類的全部對象都加了鎖）。因此若是一個線程A調用一個實例對象的非靜態 synchronized 方法，而線程B須要調用這個實例對象所屬類的靜態 synchronized 方法，是容許的，不會發生互斥現象，由於訪問靜態 synchronized 方法佔用的鎖是當前類的鎖，而訪問非靜態 synchronized 方法佔用的鎖是當前實例對象鎖。
修飾代碼塊，指定加鎖對象，對給定對象加鎖，進入同步代碼庫前要得到給定對象的鎖。和 synchronized 方法同樣，synchronized(this)代碼塊也是鎖定當前對象的。synchronized 關鍵字加到 static 靜態方法和 synchronized(class)代碼塊上都是是給 Class 類上鎖。這裏再提一下：synchronized關鍵字加到非 static 靜態方法上是給對象實例上鎖。另外須要注意的是：儘可能不要使用 synchronized(String a) 由於JVM中，字符串常量池具備緩衝功能！

下面我已一個常見的面試題爲例講解一下 synchronized 關鍵字的具體使用。

面試中面試官常常會說：「單例模式瞭解嗎？來給我手寫一下！給我解釋一下雙重檢驗鎖方式實現單利模式的原理唄！」

雙重校驗鎖實現對象單例（線程安全）

public class Singleton {

    private volatile static Singleton uniqueInstance;

    private Singleton() {
    }

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

另外，須要注意 uniqueInstance 採用 volatile 關鍵字修飾也是頗有必要。

uniqueInstance 採用 volatile 關鍵字修飾也是頗有必要的， uniqueInstance = new Singleton(); 這段代碼實際上是分爲三步執行：

爲 uniqueInstance 分配內存空間
初始化 uniqueInstance
將 uniqueInstance 指向分配的內存地址

可是因爲 JVM 具備指令重排的特性，執行順序有可能變成 1->3->2。指令重排在單線程環境下不會出先問題，可是在多線程環境下會致使一個線程得到尚未初始化的實例。例如，線程 T1 執行了 1 和 3，此時 T2 調用 getUniqueInstance() 後發現 uniqueInstance 不爲空，所以返回 uniqueInstance，但此時 uniqueInstance 還未被初始化。

使用 volatile 能夠禁止 JVM 的指令重排，保證在多線程環境下也能正常運行。

講一下 synchronized 關鍵字的底層原理

synchronized 關鍵字底層原理屬於 JVM 層面。

① synchronized 同步語句塊的狀況

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

複製代碼

經過 JDK 自帶的 javap 命令查看 SynchronizedDemo 類的相關字節碼信息：首先切換到類的對應目錄執行 javac SynchronizedDemo.java 命令生成編譯後的 .class 文件，而後執行javap -c -s -v -l SynchronizedDemo.class。

從上面咱們能夠看出：

synchronized 同步語句塊的實現使用的是 monitorenter 和 monitorexit 指令，其中 monitorenter 指令指向同步代碼塊的開始位置，monitorexit 指令則指明同步代碼塊的結束位置。當執行 monitorenter 指令時，線程試圖獲取鎖也就是獲取 monitor(monitor對象存在於每一個Java對象的對象頭中，synchronized 鎖即是經過這種方式獲取鎖的，也是爲何Java中任意對象能夠做爲鎖的緣由) 的持有權.當計數器爲0則能夠成功獲取，獲取後將鎖計數器設爲1也就是加1。相應的在執行 monitorexit 指令後，將鎖計數器設爲0，代表鎖被釋放。若是獲取對象鎖失敗，那當前線程就要阻塞等待，直到鎖被另一個線程釋放爲止。

② synchronized 修飾方法的的狀況

public class SynchronizedDemo2 {
    public synchronized void method() {
        System.out.println("synchronized 方法");
    }
}

synchronized 修飾的方法並無 monitorenter 指令和 monitorexit 指令，取得代之的確實是 ACC_SYNCHRONIZED 標識，該標識指明瞭該方法是一個同步方法，JVM 經過該 ACC_SYNCHRONIZED 訪問標誌來辨別一個方法是否聲明爲同步方法，從而執行相應的同步調用。

爲何要用線程池？

線程池提供了一種限制和管理資源（包括執行一個任務）。每一個線程池還維護一些基本統計信息，例如已完成任務的數量。

這裏借用《Java併發編程的藝術》提到的來講一下使用線程池的好處：

下降資源消耗。 經過重複利用已建立的線程下降線程建立和銷燬形成的消耗。
提升響應速度。 當任務到達時，任務能夠不須要的等到線程建立就能當即執行。
提升線程的可管理性。 線程是稀缺資源，若是無限制的建立，不只會消耗系統資源，還會下降系統的穩定性，使用線程池能夠進行統一的分配，調優和監控。

實現Runnable接口和Callable接口的區別

若是想讓線程池執行任務的話須要實現的Runnable接口或Callable接口。 Runnable接口或Callable接口實現類均可以被ThreadPoolExecutor或ScheduledThreadPoolExecutor執行。二者的區別在於 Runnable 接口不會返回結果可是 Callable 接口能夠返回結果。

備註： 工具類Executors能夠實現Runnable對象和Callable對象之間的相互轉換。（Executors.callable（Runnable task）或Executors.callable（Runnable task，Object resule））。

執行execute()方法和submit()方法的區別是什麼呢？

1)execute() 方法用於提交不須要返回值的任務，因此沒法判斷任務是否被線程池執行成功與否；

2)submit()方法用於提交須要返回值的任務。線程池會返回一個future類型的對象，經過這個future對象能夠判斷任務是否執行成功，而且能夠經過future的get()方法來獲取返回值，get()方法會阻塞當前線程直到任務完成，而使用 get（long timeout，TimeUnit unit）方法則會阻塞當前線程一段時間後當即返回，這時候有可能任務沒有執行完。

如何建立線程池

《阿里巴巴Java開發手冊》中強制線程池不容許使用 Executors 去建立，而是經過 ThreadPoolExecutor 的方式，這樣的處理方式讓寫的同窗更加明確線程池的運行規則，規避資源耗盡的風險**

Executors 返回線程池對象的弊端以下：

FixedThreadPool 和 SingleThreadExecutor ：容許請求的隊列長度爲 Integer.MAX_VALUE,可能堆積大量的請求，從而致使OOM。

CachedThreadPool 和 ScheduledThreadPool ：容許建立的線程數量爲 Integer.MAX_VALUE ，可能會建立大量線程，從而致使OOM。

方式一：經過構造方法實現

方式二：經過Executor 框架的工具類Executors來實現 咱們能夠建立三種類型的ThreadPoolExecutor：

FixedThreadPool ：該方法返回一個固定線程數量的線程池。該線程池中的線程數量始終不變。當有一個新的任務提交時，線程池中如有空閒線程，則當即執行。若沒有，則新的任務會被暫存在一個任務隊列中，待有線程空閒時，便處理在任務隊列中的任務。
SingleThreadExecutor： 方法返回一個只有一個線程的線程池。若多餘一個任務被提交到該線程池，任務會被保存在一個任務隊列中，待線程空閒，按先入先出的順序執行隊列中的任務。
CachedThreadPool： 該方法返回一個可根據實際狀況調整線程數量的線程池。線程池的線程數量不肯定，但如有空閒線程能夠複用，則會優先使用可複用的線程。若全部線程均在工做，又有新的任務提交，則會建立新的線程處理任務。全部線程在當前任務執行完畢後，將返回線程池進行復用。

對應Executors工具類中的方法如圖所示：