Netty 線程模型的總覽

本節(jié)將簡(jiǎn)單介紹一般的線程模型，Netty 中如何使用指定的線程模型，以及 Netty 過去不同的版本中使用的線程模型。你會(huì)更好的理解不同的線程模型的所有利弊。

一個(gè)線程模型指定代碼執(zhí)行，給開發(fā)人員如何執(zhí)行他們代碼的信息。這很重要，因?yàn)樗试S開發(fā)人員事先知道如何保護(hù)他們的代碼免受并發(fā)執(zhí)行的副作用。若沒有這個(gè)知識(shí)背景，即使是最好的開發(fā)人員都只能是碰運(yùn)氣，希望到最后都能這么幸運(yùn)，但這幾乎是不可能的。進(jìn)入更多的細(xì)節(jié)之前，提供一個(gè)更好的理解主題的回顧這些天大多數(shù)應(yīng)用程序做什么。

大多數(shù)現(xiàn)代應(yīng)用程序使用多個(gè)線程調(diào)度工作，因此讓應(yīng)用程序使用所有可用的系統(tǒng)資源以有效的方式。這使得很多有意義，因?yàn)榇蟛糠钟布胁恢挂粋€(gè)甚至多個(gè)CPU核心。如果一切都只有一個(gè) Thread 執(zhí)行，不可能完全使用所提供的資源。為了解決這個(gè)問題，許多應(yīng)用程序執(zhí)行多個(gè) Thread 的運(yùn)行代碼。在早期的 Java，這樣做是通過簡(jiǎn)單地按需創(chuàng)建新 Thread 時(shí)，并發(fā)工作需要做。

但很快就發(fā)現(xiàn)，這不是完美的，因?yàn)閯?chuàng)建 Thread 和回收會(huì)給他們帶來的開銷。在 Java 5 中，我們終于有了所謂的線程池，經(jīng)常緩存 Thread，用來消除創(chuàng)建和回收 Thread 的開銷。這些池由 Executor 接口提供。Java 5 提供了許多有用的實(shí)現(xiàn)，在其內(nèi)部發(fā)生顯著的變化，但思想都一脈相承的。創(chuàng)建 Thread 和重用他們提交一個(gè)任務(wù)時(shí)執(zhí)行。這可以幫助創(chuàng)建和回收線程的開銷降到最低。

下圖顯示使用一個(gè)線程池執(zhí)行一個(gè)任務(wù)，提交一個(gè)任務(wù)后會(huì)使用線程池中空閑的線程來執(zhí)行，完成任務(wù)后釋放線程并將線程重新放回線程池：

1. Runnable 表示要執(zhí)行的任務(wù)。這可能是任何東西，從一個(gè)數(shù)據(jù)庫調(diào)用文件系統(tǒng)清理。
2. 之前 runnable 移交到線程池。
3. 閑置的線程被用來執(zhí)行任務(wù)。當(dāng)一個(gè)線程運(yùn)行結(jié)束之后，它將回到閑置線程的列表新任務(wù)需要運(yùn)行時(shí)被重用。
4. 線程執(zhí)行任務(wù)

Figure 15.1 Executor execution logic

這個(gè)修復(fù) Thread 創(chuàng)建和回收的開銷，不需要每個(gè)新任務(wù)創(chuàng)建和銷毀新的 Thread 。

但使用多個(gè) Thread 提供了資源和管理成本，作為一個(gè)副作用，引入了太多的上下文切換。這種會(huì)隨著運(yùn)行的線程的數(shù)量和任務(wù)執(zhí)行的數(shù)量的增加而惡化。盡管使用多個(gè)線程在開始時(shí)似乎不是一個(gè)問題，但一旦你把真正工作負(fù)載放在系統(tǒng)上，可以會(huì)遭受到重?fù)簟?/p>

除了這些技術(shù)的限制和問題，其他問題可能發(fā)生在相關(guān)的維護(hù)應(yīng)用程序 / 框架在未來或在項(xiàng)目的生命周期里。有效地說，增加應(yīng)用程序的復(fù)雜性取決于對(duì)比。當(dāng)狀態(tài)簡(jiǎn)單時(shí)，寫一個(gè)多線程應(yīng)用程序是一個(gè)辛苦的工作！你能解決這個(gè)問題嗎？在實(shí)際的場(chǎng)景中需要多個(gè) Thread 規(guī)模，這是一個(gè)事實(shí)。讓我們看看 Netty 是解決這個(gè)問題。