Please enable JavaScript.

Coggle requires JavaScript to display documents.

Java Chapter 11 執行緒與並行API - Coggle Diagram

- - - - 一般情形，主執行緒在其它執行緒執行完run()後才會停止JVM；而若是Daemon執行緒，只要「非」Daemon都執行完，JVM就會終止，且從Daemon執行緒產生的執行緒也會是Daemon
    - - 可執行(Runnable)
        
        被阻斷(Blocked)
        
        執行中(Running)
        
        Blocked類型
        
        IO Blocked
        
        Lock Blocked
        
        Wait Blocked
    - - sleep
        
        wait
        
        notify
        
        notifyAll
        
        join
        
        interrupt
        
        stop
        
        suspend
        
        ~~resume~~ -> deprecated
        
        若要使用這些方法，最好"自行實作"執行緒應有的流程(stop, resume, suspend)
        
        join(安插執行緒)
        
        當執行緒使用join()加入至另一執行緒時，另一執行緒會等待被加入的執行緒工作完畢，然後再繼續自己的流程。
        
        表示將執行緒加入，成為另一執行緒的流程
        
        ~~stop(停止執行緒)~~ -> Deprecated
        
        執行緒完成run()方法，會進入Dead狀態，進入Dead(或已經呼叫過start()方法)的執行緒不可以呼叫start()方法，否則會拋出IllegalThreadStateException
        
        直接呼叫stop()方法，不理會你設定的釋放、取得鎖定流程，執行緒會直接釋放已鎖定物件，導致無法預期狀態。
        
        Thread的resume()、suspend()、destroy()等方法也不建議在使用。如果要停止執行緒最好自行實作，讓執行緒跑完應有的流程
    - - 執行緒都屬於某執行緒群組，若main主流程產生的thread，都屬於main執行緒群組，也可由執行緒創建時指定，其中方法可影響group中的thread。
        
        interrupt可中斷group中的thread
        
        enumerate()取得其中全部執行緒
        
        activeCount()取得執行續數量
        
        setMaxPriority()可以設定群組中執行緒的最大優先權
        
        uncaughException()方法，在群組中某個執行緒發生例外而為捕捉時，JVM會呼叫threadGroup中的此方法。也可以自行定義方法，或者subThread也可以自行定義uncaughExceptionHandler
        
        未捕捉例外處理順序，執行緒setUncaughExceptionHandler()設定的Thread.UncaughExceptionHandler、ThreadGroup.uncaughException()，再來是預設的Thread.UncaughExceptionHandler
        
        var group = new ThreadGroup("group"); var thread1 = new Thread(group, () -> { throw new RuntimeException("thread 1 測試例外"); }); thread1.setUncaughExceptionHandler((thread, throwable) -> { System.out.printf("%s: %s%n", thread.getName(), throwable.getMessage()); });
        改變了顯示堆疊追蹤的方式
- - - - InterruptException設計為可處理的收檢例外(CheckedException)，捕捉後必須思考執行緒是因為那些條件被迫中斷，才會離開blocked狀態，這時要思考該做哪些收尾動作，像是清除執行緒使用的資源之類
- - - - 缺點: 由於執行緒無法取得鎖時會造成阻斷，不正確的使用synchronized可能會造成效能低落，另一問題則是造成「死結(Dead lock)」，例如有些資源在多執行緒下彼此交叉使用，就有可能造成
- - - - 同時定義讀取鎖和寫入鎖
        
        讀取鎖: 沒有任何寫入鎖時，才能取得讀取鎖定
        
        寫入鎖: 沒有任何讀取或寫入鎖定時，才能取得寫入鎖定
        
        讀取操作，可以允許多執行並行，比原先用reentrantLock讀取效率更高
        
        可實現悲觀讀取(Pessimistic Reading)
        
        若讀取執行緒很多，寫入執行緒甚少的情況下，readWriteLock可能會使得寫入直行緒遭受「飢餓(Starvation)」問題，也就是寫入直行緒無法競爭到內部鎖，一直處於等待狀態
        
        readWriteLock範例
        ReadWriteLock lock = new ReentrantReadWriteLock(); public void add() { lock.witeLock().lock(); try { //寫入邏輯 } finally { lock.writeLock.unlock(); } } public void get() { lock.readLock().lock(); try { //讀取邏輯 } finally { lock.readLock().unlock(); } }
    - - 可支援樂觀讀取(Optimistic Reading)，解決飢餓問題 -> 可讀取資料後，是否遭到寫入直行緒的變更，再採取後續的措施(重新讀取變更後的資料，或是拋出例外)
        
        使用「鎖定戳記(stamp)」判斷是否有其他排他鎖取得
        
        stampLock範例
        StampedLock lock = new StampedLock(); public void add() { var stamp = lock.writeLock();//取得寫入鎖定 try { //writelogic } finally { lock.unlockWrite(stamp); } } public void get() { var stamp = lock.tryOptimisticRead(); if(!lock.validate(stamp)) { //查詢是否有排他的鎖定. 檢查stamp是否有更新過 //true: 沒有更動,直接回傳; false: 更動過, 重新用readLock鎖定, 再次read stamp = lock.readLock();//真正的讀取鎖定 } try { //read logic } finally { lock.unlockRead(stamp); } return value; }
        
        tryOptimisticRead()不會真正執行讀取鎖定，而是傳回鎖定戳記
        
        validate()用來檢驗戳記是不是會被其他排她鎖取得，式的話就會傳回false，如果戳記是0也會傳false
        
        被其他鎖取得的話，重新使用readLock()做真正的讀取鎖定
    - - 可達到synchronized效果，也提供額外功能(可參考)
        
        同一執行緒可用同一ReentranLock再次鎖定
        
        tryLock: 試著獲取鎖而不會阻斷直行緒，可避免dead lock
    - - Condition介面用來搭配Lock
        
        condition的await(), signal(), signalAll()取代Object的wait(), notify(), notifyAll()且可以有多個不同的等待集(Waiting Set)來做靈活應用
        
        condition範例
        Lock lock = new ReentrantLock(); Condition condition = lock.newCondition(); condition.signal()//取代Object的notify condition.await();//取代Object的wait
        
        condition不同等待集範例
        Lock lock = new ReentrantLock(); Condition producerCond = lock.newCondition();//生產者等待集 Condition consumerCond = lock.newCondition();//消費者等待集 consumerCond.signal(); & .await(); producerCond.await(); & .signal();
  - - - ExecutorService: Executor子介面，由AbstractExecutorService實作
        
        ThreadPoolExecutor: 有執行緒池的功能，結束時需要shutdown
        
        ScheduleThreadPoolExecutor: 具有執行緒池與排程功能
        
        schedule()方法用來排定Runnable或Callable實例延遲多久後執行一次，並傳回Future子介面ScheduleFuture的實例
        
        對於重複性的執行，可使用scheduleWithFixedDelay()與scheduleAtFixedRate()方法
        
        上次排定的工作拋出例外，不會影響下次排程的進行
        
        Executors的newScheduledThreadPool()和newSingleThreadScheduledExecutor()方法
        
        Executors提供靜態方法取得對應threadPool實例:newCachedThreadPool()、newFixedThreadPool()
        
        可參考
        
        提供方法
        
        submit()
        
        Runnable, return: Future
        
        Callable, return: Future
        
        invokeAll()
        
        Collection<?> Callable, return: List<Future>
        
        invokeAny()
        
        Collection<?> Callable<E>, return E
  - - - BlockQueue是Queue的子介面，新定義了put()與take()方法
        
        put(): 佇列已滿的情況下會被阻斷(blocked)
        
        take(): 佇列已空為空的情況下會被阻斷(blocked)
        
        ArrayBlockQueue是BlockQueue的實作類別，以實作put()&take()的邏輯，可以避免wait()、notify()等流程
    - - ConcurrentMap是Map的子介面，定義putIfAbsent()、remove()與replace()等方法，都是原子(Atomic)操作
        
        ConcurrentHashMap是ConcurrentMap的實作類別
        
        ConcurrentNavigableMap是ConcurrentMap的子介面
        
        實作類別ConcurrentSkipListMap: 可視為支援並行操作的TreeMap版本
- - - - 當一個執行緒修改值，其他執行緒看得到變更(立即更新到Main Memory)
        
        JMM 規範定義了 volatile、synchronized 等機制來保證可見性
    - - JMM定義操作有序性規則，確保特定條件下執行緒對變數的操作順序是可預測的
        
        JMM 保證了某些操作的執行順序不會被重新排序，以避免出現指令重排帶來的問題。例如，在 synchronized 或 volatile 關鍵字控制下，JMM 會阻止某些操作的重排序，從而保證執行緒之間的正確性。
    - - JMM保證基本數據的讀寫操作是原子性，不會被中斷
        
        某些操作（如基本型別變數的賦值）在多執行緒下是原子的，無需額外的同步措施即可保證安全。但複合操作（如 i++）則不具備原子性，需加鎖來確保操作不會被其他執行緒打斷。
  - - - 所有執行緒共享的記憶體空間，包含所有共享變數
    - - 每個執行緒私有的記憶體空間，用於儲存從主記憶體中讀取的變數副本，且執行緒只能雌做工作記憶體中的變數，而不能操作主記憶體的變數
    - - 是指令序列，用於強制刷新或加載CPU的快取，在多執行緒的情況下，可以保證記憶體操作執行順序，確保執行緒之間的可見性和有序性
    - - 設計原因
        
        CPU為提高執行效能，會使用多層次的快取(L1, L2, L3)，這些快取儲存了部分Main Memory，以便快速存取，減少每次讀寫變數都必須與相對較慢Main memory進行操作的開銷
      - 設計原理
        
        存取速度
        
        快取記憶體(cache)的存取速度遠高於記憶體，透過將經常使用的資料放置於快取中，CPU可大幅將低存取延遲，提升執行效率
        
        局部性原則
        
        程式的執行具有空間局部性及時間侷限性
        
        空間局部性: 訪問相鄰記憶體位置的傾向
        
        時間局部性: 重複訪問相同記憶體位置的傾向
        
        快取記憶體利用這些傾向，預先載入並保持最近使用的資料
        
        一致性協議
        
        CPU採取快取一致性協議(MESI)來確保各核心的快取資料的一致性，當某核心改變了變數，其他核心的快取會被標記或更新，確保最終看到一致的數據
      - 主記憶體與工作記憶體的操作互動
        
        讀取資料: Thread讀取變數時，先檢查快取中是否有該變數的副本，如果有(快取命中)，直接從快取中讀取；否則從Main memory讀取並載入快取(快取未命中)
        
        寫入資料: Thread修改變數時，先修改快取中的副本，MESI會確保資料的一致性，修改後的資料最終寫回Main memroy