Swoole的生命周期

php-fpm中的生命周期

傳統(tǒng)基于php-fpm的web開發(fā)通常淡化了全局期變量的影響，這對于開發(fā)者而言，顯然是降低了許多上手難度的；但也導致了許多新人對全局期變量會產(chǎn)生的影響沒有深刻理解。

我們知道，php-fpm收到請求后會分配一個work進程去處理這條請求，而work會去讀取并執(zhí)行.php文件(在通常情基于框架的開發(fā)中，這個.php文件可能是index.php)。也就是說在傳統(tǒng)模式中，每個請求都是獨立在自己的進程中執(zhí)行的，因為進程是隔離的而php-fpm又是同步阻塞的，所以我們可以很好的清楚和了解是誰在什么時候創(chuàng)建了變量、修改了變量、銷毀了變量。

簡單舉個例子

可可醬是商店的一名售貨員，這個店只有他一個人。當客戶來了之后需要購買一瓶可樂，可可醬檢查了貨架確認有可樂，隨后告訴客戶這瓶可樂價格是￥3.5元，客戶付錢給可可醬，可可醬收到錢后把可樂交給了客戶。

后來發(fā)現(xiàn)客人太多，只有可可醬一個人的時候后面的客戶需要排隊很久，于是老板決定再雇一名售貨員，于是加入了小明。

還是上面的場景，但是由于小明的加入，小明和可可醬同時接待了2名客戶，可可醬檢查了貨架確認還有一箱可樂的時候，和客人溝通可樂的價格時，小明的客戶需要購買一箱可樂，于是小明就取走了一箱可樂，當可可醬收了錢準備拿可樂的時候，發(fā)現(xiàn)沒有可樂了，然后被客戶打了一頓。

在上面的場景中，就是一個變量被修改而導致后續(xù)邏輯混亂的場景，在傳統(tǒng)的fpm開發(fā)中，往往只會在訪問數(shù)據(jù)庫的時候出現(xiàn)這種場景。但是如果假設一個fpm進程可以同時處理多條請求的時候，你如果將用戶信息存放在全局變量中，那么你就無法再可靠的判斷當前用戶是誰了。

swoole_server中對象的4層生命周期

以下內容摘自swoole文檔

開發(fā)swoole程序與普通LAMP下編程有本質區(qū)別。在傳統(tǒng)的Web編程中，PHP程序員只需要關注request到達，request結束即可。而在swoole程序中程序員可以操控更大范圍，變量/對象可以有四種生存周期。

變量、對象、資源、require/include的文件等下面統(tǒng)稱為對象

程序全局期

在swoole_server->start之前就創(chuàng)建好的對象，我們稱之為程序全局生命周期。這些變量在程序啟動后就會一直存在，直到整個程序結束運行才會銷毀。

有一些服務器程序可能會連續(xù)運行數(shù)月甚至數(shù)年才會關閉/重啟，那么程序全局期的對象在這段時間持續(xù)駐留在內存中的。程序全局對象所占用的內存是Worker進程間共享的，不會額外占用內存。

這部分內存會在寫時分離（COW），在Worker進程內對這些對象進行寫操作時，會自動從共享內存中分離，變?yōu)?strong>進程全局對象。

程序全局期include/require的代碼，必須在整個程序shutdown時才會釋放，reload無效

進程全局期

swoole擁有進程生命周期控制的機制，一個Worker子進程處理的請求數(shù)超過max_request配置后，就會自動銷毀。Worker進程啟動后創(chuàng)建的對象（onWorkerStart中創(chuàng)建的對象），在這個子進程存活周期之內，是常駐內存的。onConnect/onReceive/onClose 中都可以去訪問它。

進程全局對象所占用的內存是在當前子進程內存堆的，并非共享內存。對此對象的修改僅在當前Worker進程中有效
進程期include/require的文件，在reload后就會重新加載

會話期

onConnect到onClose是一次TCP的會話周期，http keep-alive時，一個連接可能會有多個request。 http是無狀態(tài)的，一個用戶可能也不止一個連接，可以通過創(chuàng)建一個session來關聯(lián)同一個用戶的不同請求。

請求期

請求期就是指一個完整的請求發(fā)來，也就是onReceive收到請求開始處理，直到返回結果發(fā)送response。這個周期所創(chuàng)建的對象，會在請求完成后銷毀。

swoole中請求期對象與普通PHP程序中的對象就是一樣的。請求到來時創(chuàng)建，請求結束后銷毀。

總結

在Swoole中，一個work進程處理完請求后并不會銷毀(甚至可能同時處理多個請求)，所以務必要明確你創(chuàng)建的變量的生命周期，以防止出現(xiàn)邏輯上的問題。