Java Concurrency: Thread-Per-Message，最基本的執行緒使用方法

最古老的執行緒使用方法Thread Per Message

Photo by drmakete lab on Unsplash

前言

Thread per message設計模式，是Java古早的連線請求處理方式，在多年前網路還不像現在如此發達，連線數量每秒還沒動則幾萬的時代，Thread Per Message可說是網路應用程式的基本開發方法，但隨著時代進步Thread Per Message也跟著被淘汰，就讓我們來看看什麼是Thread Per Message

方法

Thread Per Message如同字面意義，每當有連線訊息請求時，就開一個執行緒處理此請求，有修過作業系統都知道每開一個執行緒時，Sub Thread會Fork Main Thread，白話一點就是複製Main Thread的記憶體場景，讓Sub Thread可以運作，這樣的方法如果連線數量暴增就會導致OOM(Out Of Memory)。而隨著連線數的上升，現代的Java工程師們也開始使用Worker Thread與Producter Consumer模式消化大量的連線，這兩個模式在之後的文章也會依序介紹。

範例

這篇文章的範例使用Java網路開發作為範例，每當Socket接到連線請求就開一個執行緒處理，為了模擬處理所以Sleep 5秒，並且對Client回傳Hi字串。

Server

Client

優點

1. 當連線數量不多(或是任務請求數量不多時)，可以直接使用此模式快速開發，直接new Thread就完成了
2. 邏輯非常直接

缺點

1. 若是程式碼非常關鍵與核心，則完全不要這樣做，阿里巴巴內部其實也明言禁止Java直接new Thread了，直接new Thread很難監控到每個Thread的執行(應該使用執行緒池處理)
2. OOM問題，若開的Thread非常多就會造成OOM

結論

1. Thread Per Message是Java網路開發的最古早的處理方式
2. 現在連線動則幾萬，這樣的設計已不再適合
3. 但是若只是小型DEMO尋求快速，不用太多的監控則可以嘗試看看
4. 後續要介紹的Worker Thread和Producter Consumer模式，都是當Thread Per Message不在可用時的處理方案