建站
咨詢
售后
建站咨詢
新聞中心
并發(fā)編程的核心是什么?
- 同步
- 互斥
- 分工
并發(fā)編程解決分工問題有哪些設(shè)計模式?
- Thread-Per-Message模式
- Worker Thread模式
- 生產(chǎn)者-消費者模式
- …
簡單說說Thread-Per-Message模式
將事情委托他人代辦，有個好處，就是可以專心做自己事了。
編程也是這樣，比如寫一個HTTP Server，很顯然只能在主線程中接收請求，而不能處理HTTP請求，因為若在主線程中處理HTTP請求，則同一時間只能處理一個請求，太慢了!這時就可以采取委托的思路，創(chuàng)建一個子線程，委托子線程去處理HTTP請求。
這種騷操作，在并發(fā)領(lǐng)域就是Thread-Per-Message模式(后文簡稱為 TPM)：為每個任務(wù)分配一個獨立線程。這也是最簡單的一種分工方案。
Java 線程實現(xiàn)TPM
TPM最經(jīng)典的應(yīng)用場景就是網(wǎng)絡(luò)編程的服務(wù)端實現(xiàn)。
服務(wù)端為每個客戶端請求創(chuàng)建一個獨立線程，當(dāng)線程處理完請求后，自動銷毀，這是最簡單的并發(fā)處理網(wǎng)絡(luò)請求的方法。
- 比如echo程序的服務(wù)端
但該實現(xiàn)不可能在實際生產(chǎn)使用，因為Java線程實在是個重量級對象：
- 創(chuàng)建線程比較耗時
- 線程占用的內(nèi)存也較大
所以，為每個請求創(chuàng)建一個新的線程并不適合互聯(lián)網(wǎng)的高并發(fā)場景。
難道TPM只是空想國?如果換一種實現(xiàn)，估計你會想到線程池。方向沒問題，但引入線程池也會增加復(fù)雜度。
換個角度看問題，語言、工具、框架應(yīng)該是幫助我們更高性能實現(xiàn)方案的，而不是用來否定方案的，TPM作為一種最簡單的分工方案，Java語言支持不了，顯然是Java語言本身設(shè)計問題。
Java語言里，Java線程是和操作系統(tǒng)線程一一對應(yīng)的，這種做法本質(zhì)上是將Java線程的調(diào)度權(quán)完全委托給操作系統(tǒng)，而操作系統(tǒng)在這方面非常成熟，所以這種做法的好處是穩(wěn)定、可靠，但是也繼承了操作系統(tǒng)線程的缺點：創(chuàng)建成本高。為了解決這個缺點，Java并發(fā)包里提供了線程池等工具類。這個思路在很長一段時間里都是很穩(wěn)妥的方案，但是這個方案并不是唯一的方案。
業(yè)界還有另外一種方案：
輕量級線程
該方案在Java領(lǐng)域老牌度不高，但和Go里的協(xié)程，本質(zhì)都是一種輕量級線程。其創(chuàng)建成本很低，和創(chuàng)建一個普通對象類似;并且創(chuàng)建速度和內(nèi)存占用相比os線程至少有一個數(shù)量級提升，所以基于輕量級線程實現(xiàn)TPM就完全沒有問題。
Java也意識到輕量級線程的意義，OpenJDK的Loom項目就是要解決Java語言的輕量級線程問題。Loom 中的輕量級線程稱為Fiber。
使用Fiber實現(xiàn)TPM。
Loom在設(shè)計輕量級線程時，也充分參考了當(dāng)前Java線程的使用方式，所以學(xué)習(xí)成本還是很低的。只需將new Thread(()->{…}).start()換成 Fiber.schedule(()->{})。
在 Java 的高并發(fā)領(lǐng)域，雖然不具備可行性，不過對一些并發(fā)度沒那么高的異步場景，例如定時任務(wù)，采用 TPM完全沒問題。
本文轉(zhuǎn)載自微信公眾號「JavaEdge」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系JavaEdge公眾號。
網(wǎng)站標(biāo)題：并發(fā)編程領(lǐng)域的Thread-Per-Message設(shè)計模式到底是什么？
網(wǎng)站鏈接：http://m.fisionsoft.com.cn/article/djgsogg.html
