swoole項目開發思惟轉換 -- 長駐內存

從上篇的執行流程，能夠得出第一個須要思惟轉換的點：

Swoole是徹底的長駐內存的

這個是和web開發第一個很大的不一樣，以前咱們在作web開發，基本不怎麼考慮內存控制的問題，這裏從兩個方面來進行結比：

• 性能加速

  長駐內存一個最大的好處就是能夠性能加速，主要經過下面幾個點來進行：

            a)  請求全局共享。在fpm模式下，咱們處理一個請求，一般會有一些空消耗,好比框架共用文件加載，配置文件加載，那麼在swoole中，能夠在onworkerstart的時候提早一次性把一些必要的文件和配置加載好，沒必要每次receive重複加載一遍，這樣能提高不小的性能

           b)  能夠作鏈接池了

   

• 隱患

  雖然長駐內存能有不小的性能加速，但因爲web開發時候造成的思惟定勢，很容易形成內存泄漏，因此要注意幾下幾點：

           a)  資源的釋放，若是是公用的資源，建議在onworkerstart裏提早建立好，不然在onReceive裏，必定要及時的釋放。

           b)  static數組，這個是很容易踩到的坑，static數組若是存在只增不減，那最終就會致使oom了。

           c)   單例或全局註冊數，單例能夠很好的控制內存泄漏，但因爲swoole裏的單例是全請求共享，因此一但初始化了一個類以後，上一個請求修改的這個類，會影響到下一個請求，這也是不少人會忽略掉的。舉個很典型的例子，如今redis用的比較多了，在swoole，單例了一個redis類，我在某個請求忽然執行了selectDb, 那就致使了下面全部的請求可能就get數據失敗了。

   

• 超全局變量     

  超全局變量是phper用的比較多的，因爲swoole是多進程的架構，若是在worker裏進行task投遞以後，在task裏是沒法獲得worker裏的數據的，因此這個坑也是常常被踩到，如今的框架基本拋棄直接經過超全局變量的方式來獲取數據，基本都封裝了一套取參數的方法，因此在swoole裏強烈推薦用此方法，不論是worker轉到task仍是task轉到worker, 我只要把獲取到的外部數據經過框架的參數初始化這樣的流程，那麼在框架內部用就是安全的。

 

固然，swooele也提供了和fpm相似的max_request機制，能夠控制每一個worker或task進程處理必定請求總數以後，自動退出，由管理進程從新拉起一個新的worker或task進程，從而達到內存徹底釋放的目的。

 

總之，在長駐內存的swoole下進行項目開發，能夠培養咱們更好的控制內存，更清楚的瞭解程序的細節，這個思惟能夠擴展到其餘服務器編程的語言中，對自個人提高是頗有幫助的。