唉，被坑慘了！

大家好，我是小林。

前幾天基金還大漲了一波，結(jié)果今天一早上打開(kāi)支付寶，發(fā)現(xiàn)昨天的基金收益直接 -3000多。。。

你說(shuō)不心疼是假的，但是我短期內(nèi)也不會(huì)賣(mài)出，所以在我不賣(mài)出的時(shí)候，它就是個(gè)數(shù)字，而且現(xiàn)在總體收益還是正數(shù)的，不慌！

老讀者應(yīng)該知道，我是今年年初入坑基金的韭零后，選了幾個(gè)基金后，就一直無(wú)腦定投，風(fēng)雨無(wú)阻。

在 3 月份的時(shí)候，總體收益最低的時(shí)候是 -10000，不過(guò)由于一直在持續(xù)定投，在 5 月份收益已經(jīng)從負(fù)數(shù)變成正數(shù)了，收益也不算多，就小幾千。

這玩意漲跌每天都在發(fā)生，我就偶爾打開(kāi)看看收益的情況，每次打開(kāi)驚喜筆比較少，驚嚇到是比較多些。

好了，基金的事情就說(shuō)到這了，我也算個(gè)反面教材，大家看個(gè)樂(lè)就好。

身為技術(shù)博主，那肯定還是得說(shuō)說(shuō)技術(shù)的事情。

昨天有位讀者被坑了，問(wèn)了我這么個(gè)問(wèn)題：

大致意思就是，他看了一個(gè)面經(jīng)，說(shuō)虛擬內(nèi)存是 2G 大小，然后他看了我的圖解系統(tǒng) PDF 里說(shuō)虛擬內(nèi)存是 4G，然后他就懵逼了。

其實(shí)他看這個(gè)面經(jīng)很有問(wèn)題，沒(méi)有說(shuō)明是什么操作系統(tǒng)，以及是多少位操作系統(tǒng)。

因?yàn)椴煌牟僮飨到y(tǒng)和不同位數(shù)的操作系統(tǒng)，虛擬內(nèi)存可能是不一樣多。

Windows 系統(tǒng)我不了解，我就說(shuō)說(shuō) Linux 系統(tǒng)。?

在 Linux 操作系統(tǒng)中，虛擬地址空間的內(nèi)部又被分為內(nèi)核空間和用戶(hù)空間兩部分，不同位數(shù)的系統(tǒng)，地址 空間的范圍也不同。比如最常?的 32 位和 64 位系統(tǒng)，如下所示:

通過(guò)這里可以看出:

• 32 位系統(tǒng)的內(nèi)核空間占用 1G ，位于最高處，剩下的 3G 是用戶(hù)空間;

• 64 位系統(tǒng)的內(nèi)核空間和用戶(hù)空間都是 128T ，分別占據(jù)整個(gè)內(nèi)存空間的最高和最低處，剩下的中
  間部分是未定義的。

接著，來(lái)看看讀者那個(gè)面經(jīng)題目：一個(gè)進(jìn)程最多可以創(chuàng)建多少個(gè)線(xiàn)程？

這個(gè)問(wèn)題跟兩個(gè)東西有關(guān)系：

• 進(jìn)程的虛擬內(nèi)存空間上限，因?yàn)閯?chuàng)建一個(gè)線(xiàn)程，操作系統(tǒng)需要為其分配一個(gè)棧空間，如果線(xiàn)程數(shù)量越多，所需的?？臻g就要越大，那么虛擬內(nèi)存就會(huì)占用的越多。

• 系統(tǒng)參數(shù)限制，雖然 Linux 并沒(méi)有內(nèi)核參數(shù)來(lái)控制單個(gè)進(jìn)程創(chuàng)建的最大線(xiàn)程個(gè)數(shù)，但是有系統(tǒng)級(jí)別的參數(shù)來(lái)控制整個(gè)系統(tǒng)的最大線(xiàn)程個(gè)數(shù)。

我們先看看，在進(jìn)程里創(chuàng)建一個(gè)線(xiàn)程需要消耗多少虛擬內(nèi)存大??？

我們可以執(zhí)行 ulimit -a 這條命令，查看進(jìn)程創(chuàng)建線(xiàn)程時(shí)默認(rèn)分配的?？臻g大小，比如我這臺(tái)服務(wù)器默認(rèn)分配給線(xiàn)程的?？臻g大小為 8M。

在前面我們知道，在 32 位 Linux 系統(tǒng)里，一個(gè)進(jìn)程的虛擬空間是 4G，內(nèi)核分走了1G，留給用戶(hù)用的只有 3G。

那么假設(shè)創(chuàng)建一個(gè)線(xiàn)程需要占用 10M 虛擬內(nèi)存，總共有 3G 虛擬內(nèi)存可以使用。于是我們可以算出，最多可以創(chuàng)建差不多 300 個(gè)（3G/10M）左右的線(xiàn)程。

如果你想自己做個(gè)實(shí)驗(yàn)，你可以找臺(tái) 32 位的 Linux 系統(tǒng)運(yùn)行下面這個(gè)程序：

由于我手上沒(méi)有 32 位的系統(tǒng)，我這里貼一個(gè)網(wǎng)上別人做的測(cè)試結(jié)果：

如果想使得進(jìn)程創(chuàng)建上千個(gè)線(xiàn)程，那么我們可以調(diào)整創(chuàng)建線(xiàn)程時(shí)分配的?？臻g大小，比如調(diào)整為 512k：

$?ulimit?-s?512
說(shuō)完 32 位系統(tǒng)的情況，我們來(lái)看看 64 位系統(tǒng)里，一個(gè)進(jìn)程能創(chuàng)建多少線(xiàn)程呢？

我的測(cè)試服務(wù)器的配置：

• 64 位系統(tǒng)；

• 2G 物理內(nèi)存；

• 單核 CPU。

64 位系統(tǒng)意味著用戶(hù)空間的虛擬內(nèi)存最大值是 128T，這個(gè)數(shù)值是很大的，如果按創(chuàng)建一個(gè)線(xiàn)程需占用 10M ?？臻g的情況來(lái)算，那么理論上可以創(chuàng)建 128T/10M 個(gè)線(xiàn)程，也就是 1000多萬(wàn)個(gè)線(xiàn)程，有點(diǎn)魔幻！

所以按 64 位系統(tǒng)的虛擬內(nèi)存大小，理論上可以創(chuàng)建無(wú)數(shù)個(gè)線(xiàn)程。

事實(shí)上，肯定創(chuàng)建不了那么多線(xiàn)程，除了虛擬內(nèi)存的限制，還有系統(tǒng)的限制。

比如下面這三個(gè)內(nèi)核參數(shù)的大小，都會(huì)影響創(chuàng)建線(xiàn)程的上限：

• /proc/sys/kernel/threads-max，表示系統(tǒng)支持的最大線(xiàn)程數(shù)，默認(rèn)值是?14553；

• /proc/sys/kernel/pid_max，表示系統(tǒng)全局的 PID 號(hào)數(shù)值的限制，每一個(gè)進(jìn)程或線(xiàn)程都有 ID，ID 的值超過(guò)這個(gè)數(shù)，進(jìn)程或線(xiàn)程就會(huì)創(chuàng)建失敗，默認(rèn)值是?32768；

• /proc/sys/vm/max_map_count，表示限制一個(gè)進(jìn)程可以擁有的VMA(虛擬內(nèi)存區(qū)域)的數(shù)量，具體什么意思我也沒(méi)搞清楚，反正如果它的值很小，也會(huì)導(dǎo)致創(chuàng)建線(xiàn)程失敗，默認(rèn)值是?65530。

那接下針對(duì)我的測(cè)試服務(wù)器的配置，看下一個(gè)進(jìn)程最多能創(chuàng)建多少個(gè)線(xiàn)程呢？

我在這臺(tái)服務(wù)器跑了前面的程序，其結(jié)果如下：

可以看到，創(chuàng)建了 14374 個(gè)線(xiàn)程后，就無(wú)法在創(chuàng)建了，而且報(bào)錯(cuò)是因?yàn)橘Y源的限制。

前面我提到的?threads-max?內(nèi)核參數(shù)，它是限制系統(tǒng)里最大線(xiàn)程數(shù)，默認(rèn)值是 14553。

我們可以運(yùn)行那個(gè)測(cè)試線(xiàn)程數(shù)的程序后，看下當(dāng)前系統(tǒng)的線(xiàn)程數(shù)是多少，可以通過(guò)?top -H?查看。

左上角的 Threads 的數(shù)量顯示是 14553，與?threads-max?內(nèi)核參數(shù)的值相同，所以我們可以認(rèn)為是因?yàn)檫@個(gè)參數(shù)導(dǎo)致無(wú)法繼續(xù)創(chuàng)建線(xiàn)程。

那么，我們可以把 threads-max 參數(shù)設(shè)置成?99999:

echo?99999?>?/proc/sys/kernel/threads-max
設(shè)置完 threads-max 參數(shù)后，我們重新跑測(cè)試線(xiàn)程數(shù)的程序，運(yùn)行后結(jié)果如下圖：

可以看到，當(dāng)進(jìn)程創(chuàng)建了 32326 個(gè)線(xiàn)程后，就無(wú)法繼續(xù)創(chuàng)建里，且報(bào)錯(cuò)是無(wú)法繼續(xù)申請(qǐng)內(nèi)存。

此時(shí)的上限個(gè)數(shù)很接近?pid_max?內(nèi)核參數(shù)的默認(rèn)值（32768），那么我們可以嘗試將這個(gè)參數(shù)設(shè)置為 99999：

echo?99999?>?/proc/sys/kernel/pid_max
設(shè)置完 pid_max 參數(shù)后，繼續(xù)跑測(cè)試線(xiàn)程數(shù)的程序，運(yùn)行后結(jié)果創(chuàng)建線(xiàn)程的個(gè)數(shù)還是一樣卡在了 32768 了。

當(dāng)時(shí)我也挺疑惑的，明明 pid_max 已經(jīng)調(diào)整大后，為什么線(xiàn)程個(gè)數(shù)還是上不去呢？

后面經(jīng)過(guò)查閱資料發(fā)現(xiàn)，max_map_count?這個(gè)內(nèi)核參數(shù)也是需要調(diào)大的，但是它的數(shù)值與最大線(xiàn)程數(shù)之間有什么關(guān)系，我也不太明白，只是知道它的值是會(huì)限制創(chuàng)建線(xiàn)程個(gè)數(shù)的上限。

然后，我把 max_map_count 內(nèi)核參數(shù)也設(shè)置成后 99999：

echo?99999?>?/proc/sys/kernel/pid_max?
繼續(xù)跑測(cè)試線(xiàn)程數(shù)的程序，結(jié)果如下圖：

當(dāng)創(chuàng)建差不多 5 萬(wàn)個(gè)線(xiàn)程后，我的服務(wù)器就卡住不動(dòng)了，CPU 都已經(jīng)被占滿(mǎn)了，畢竟這個(gè)是單核 CPU，所以現(xiàn)在是 CPU 的瓶頸了。

我只有這臺(tái)服務(wù)器，如果你們有性能更強(qiáng)的服務(wù)器來(lái)測(cè)試的話(huà)，有興趣的小伙伴可以去測(cè)試下。

接下來(lái)，我們換個(gè)思路測(cè)試下，把創(chuàng)建線(xiàn)程時(shí)分配的?？臻g調(diào)大，比如調(diào)大為 100M，在大就會(huì)創(chuàng)建線(xiàn)程失敗。

ulimit?-s?1024000
設(shè)置完后，跑測(cè)試線(xiàn)程的程序，其結(jié)果如下：

總共創(chuàng)建了 26390 個(gè)線(xiàn)程，然后就無(wú)法繼續(xù)創(chuàng)建了，而且該進(jìn)程的虛擬內(nèi)存空間已經(jīng)高達(dá) 25T，要知道這臺(tái)服務(wù)器的物理內(nèi)存才 2G。

為什么物理內(nèi)存只有 2G，進(jìn)程的虛擬內(nèi)存卻可以使用 25T 呢？

因?yàn)樘摂M內(nèi)存并不是全部都映射到物理內(nèi)存的，程序是有局部性的特性，也就是某一個(gè)時(shí)間只會(huì)執(zhí)行部分代碼，所以只需要映射這部分程序就好。

你可以從上面那個(gè) top 的截圖看到，雖然進(jìn)程虛擬空間很大，但是物理內(nèi)存（RES）只有使用了 400M 。

好了，簡(jiǎn)單總結(jié)下：

• 32 位系統(tǒng)，用戶(hù)態(tài)的虛擬空間只有 3G，如果創(chuàng)建線(xiàn)程時(shí)分配的?？臻g是 10M，那么一個(gè)進(jìn)程最多只能創(chuàng)建 300 個(gè)左右的線(xiàn)程。

• 64 位系統(tǒng)，用戶(hù)態(tài)的虛擬空間大到有 128T，理論上不會(huì)受虛擬內(nèi)存大小的限制，而會(huì)受系統(tǒng)的參數(shù)或性能限制。

辛苦了你們了，深夜還讓你們跑來(lái)看技術(shù)文。

怪我！