volatile：可見性和順序性，不保證原子性
單例模式
監控執行緒生命週期的observable:
採用乙個observable介面來獲取任務執行的狀態，主要想法是重寫run方法。在任務建立，開始，結束，錯誤時介入乙個方法，用來進行處理。同時維護乙個指示任務狀態的類變數。採用模板設計模式的方式，將具體業務寫成方法介面，在run方法中呼叫。
single thread execution設計模式：強制每次都是只有乙個執行緒能獲得所有所需資源
讀寫鎖分離設計模式，拓展：stampedlock
讀寫鎖其實是乙個工廠類方法，其中提供了讀鎖和寫鎖，並且提供了當前讀鎖的個數，寫鎖的個數，等待寫鎖的個數。而讀鎖和寫鎖只負責加鎖和解鎖。讀鎖和寫鎖都會使用讀寫鎖中的乙個共有的mutex object作為讀寫鎖的共享變數。在讀鎖中，先要請求mutex，之後，如果是有寫鎖或者有等待的寫鎖並且偏好寫鎖，則使用wait，否則就可以加鎖。寫鎖則是只要當前有讀鎖或者寫鎖都會進入等待。解鎖則是常規的喚醒其他等待中程序，並且根據需要改變偏好標記。
不可變物件設計模式：每一次都是返回乙個新的物件
future模式：執行緒將任務提交後繼續其他任務，會調介面或者顯示方法獲得結果。、
首先future只用來判斷任務是否結束以及得到結果，而任務的狀態和結果都是由例項變數控制的。所謂的結果也是由執行緒執行完了任務後傳入future類例項的。
那麼控制的方法就是：最開始future的任務標記設為未結束，結果變數為空，獲得結果的方法get和接收result的方法future將結果設為共享變數。get方法在請求時，發現任務標記為false就會進入阻塞等待。future方法在請求後就會設定result並改變任務標記為已結束，並喚醒get程序。
而提交任務的類只負責新建乙個future,啟動執行緒，並且執行任務，以及在任務結束後呼叫對應future的finish方法。
拓展：completablefuture
執行緒上下文設計模式：為每乙個thread設定threadlocalmap使得乙個執行緒下有全域性的資訊，避免層層傳遞資訊
balking設計模式：多個執行緒去修改乙個共享變數時（做結果相同的操作），當發現有其他執行緒已經先開始做這個操作後，自動放棄這次的行為。
latch設計模式：為乙個任務設定多個前置任務時，當這些前置任務彼此不影響時，可以併發執行這些任務，並且直到所有前置任務完成，該任務才開始。
thread-per-message模式即是為每乙個訊息開闢乙個執行緒（或者使用執行緒池），來維護一系列訊息的傳輸。
two-phase-message模式用於將結束程序設定為兩個階段，增加了新的釋放資源的階段，將要釋放資源的執行緒放入乙個佇列中在最後從佇列中取出執行緒做最後的資源釋放。
worker-thread 模式類似於流水線，上游提供任務，流水線中得到產品並且使用其中的步驟方法。
facade設計模式，翻譯為外觀模式，主要是將一系列操作進行封裝抽象成乙個新的系統層，在使用的時候，客戶端只需要去呼叫這個系統的乙個方法就可以完成連續的為乙個目的而服務的操做了。
執行緒池和設計模式
執行緒池 一種執行緒使用模式。執行緒過多會帶來排程開銷，進而影響快取區域性性和整體效能。而執行緒池維護著多個 執行緒，等待著監督管理者分配可併發執行的任務。這避免了在處理短時間任務時建立與銷毀執行緒的代價。執行緒池不僅能夠保證核心的充分利用，還能防止過分排程。應 用 需要大量的執行緒來完成任務，且完...
設計模式 執行緒池模式
定義 worker thread的角色 例項應用 利用同步塊來處理，vector容器來儲存客戶端請求。利用vector來儲存，依舊是每次集合的最後乙個位置新增請求，從開始位置移除請求來處理。在channel有快取請求方法和處理請求方法，利用生成者與消費者模式來處理儲存請求，利用正向等待來判斷任務池的...
多執行緒設計模式之Future 設計模式
future 設計模式就好像我們在傳送ajax請求一樣，頁面是非同步的進行後台處理，使用者無須一直等待請求的結果，可以繼續瀏覽或操作其他內容。這個圖就很清楚的講清楚了這個模式，當客戶端傳送資料過去，服務端會進行處理，但是為了保證使用者體驗，使用者可以進行其他操作，當使用者需要該資料的時候，進行請求即...