什么是Thread-Per-Message設計模式

這篇文章主要講解了“什么是Thread-Per-Message設計模式”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“什么是Thread-Per-Message設計模式”吧！

并發編程的核心是什么?

• 同步

• 互斥

• 分工

并發編程解決分工問題有哪些設計模式?

• Thread-Per-Message模式

• Worker Thread模式

• 生產者-消費者模式

• …

簡單說說Thread-Per-Message模式

將事情委托他人代辦，有個好處，就是可以專心做自己事了。

編程也是這樣，比如寫一個HTTP  Server，很顯然只能在主線程中接收請求，而不能處理HTTP請求，因為若在主線程中處理HTTP請求，則同一時間只能處理一個請求，太慢了!這時就可以采取委托的思路，創建一個子線程，委托子線程去處理HTTP請求。

這種騷操作，在并發領域就是Thread-Per-Message模式(后文簡稱為 TPM)：為每個任務分配一個獨立線程。這也是最簡單的一種分工方案。

Java 線程實現TPM

TPM最經典的應用場景就是網絡編程的服務端實現。

服務端為每個客戶端請求創建一個獨立線程，當線程處理完請求后，自動銷毀，這是最簡單的并發處理網絡請求的方法。

• 比如echo程序的服務端

但該實現不可能在實際生產使用，因為Java線程實在是個重量級對象：

• 創建線程比較耗時

• 線程占用的內存也較大

所以，為每個請求創建一個新的線程并不適合互聯網的高并發場景。

難道TPM只是空想國?如果換一種實現，估計你會想到線程池。方向沒問題，但引入線程池也會增加復雜度。

換個角度看問題，語言、工具、框架應該是幫助我們更高性能實現方案的，而不是用來否定方案的，TPM作為一種最簡單的分工方案，Java語言支持不了，顯然是Java語言本身設計問題。

Java語言里，Java線程是和操作系統線程一一對應的，這種做法本質上是將Java線程的調度權完全委托給操作系統，而操作系統在這方面非常成熟，所以這種做法的好處是穩定、可靠，但是也繼承了操作系統線程的缺點：創建成本高。為了解決這個缺點，Java并發包里提供了線程池等工具類。這個思路在很長一段時間里都是很穩妥的方案，但是這個方案并不是唯一的方案。

業界還有另外一種方案：

輕量級線程

該方案在Java領域知名度不高，但和Go里的協程，本質都是一種輕量級線程。其創建成本很低，和創建一個普通對象類似;并且創建速度和內存占用相比os線程至少有一個數量級提升，所以基于輕量級線程實現TPM就完全沒有問題。

Java也意識到輕量級線程的意義，OpenJDK的Loom項目就是要解決Java語言的輕量級線程問題。Loom 中的輕量級線程稱為Fiber。

使用Fiber實現TPM。

Loom在設計輕量級線程時，也充分參考了當前Java線程的使用方式，所以學習成本還是很低的。只需將new  Thread(()->{…}).start()換成 Fiber.schedule(()->{})。

在 Java 的高并發領域，雖然不具備可行性，不過對一些并發度沒那么高的異步場景，例如定時任務，采用 TPM完全沒問題。

感謝各位的閱讀，以上就是“什么是Thread-Per-Message設計模式”的內容了，經過本文的學習后，相信大家對什么是Thread-Per-Message設計模式這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！