STL在伺服器程式開發中存在的三大問題

    當我問及一些同行的朋友對於伺服器程式中STL的使用方式的時候，他們都回答在自己公司的伺服器程式開發中，一般都不使用STL。
   為何標準庫在伺服器程式開發環境中受到冷遇呢？我覺得在伺服器程式這種高穩定性、高效能、高並發的環境下，STL存在著三大問題。

    問題一：不能確定STL如何管理記憶體。假設就按照STL預設的方法來管理內容，則伺服器在長時間的分配和釋放記憶體後，容易導致記憶體片段，對伺服器的穩定有影響。然而，如果沒有閱讀過STL的源碼，誰又能確切地得知STL是如何管理記憶體的呢？雖然可以在STL中使用自己的分配器，又能夠確認STL的某些部分不會在分配器之外進行記憶體配置呢？
    當然，記憶體管理問題不是STL帶來的問題，任何伺服器程式本身都要考慮這個問題。原因在極少有人去閱讀STL的源碼，去瞭解STL的內部實現機理。因為不瞭解，所以懷疑；因為懷疑，所以不輕易使用。

    問題二：不能確定STL在海量資料下的表現。伺服器一般都是海量的記憶體，為了提高效能大量資料儲存在記憶體中。在非常大的規模的資料下，STL一定能夠滿足穩定性和效率的需求嗎？

    問題三：不能確定STL在多線程環境下的表現。以上的記憶體和規模的問題可以通過加深對STL的瞭解和測試來解決，但是多線程下的並發問題就不是那麼容易解決了。STL不是安全執行緒的，在多線程環境下，對STL容器的操作都要加鎖來確保正確。然後，部分高效能的場合，需要對“讀-讀”條件下並發進行最佳化，以及某些鎖無關的特殊條件可以不加鎖，甚至是採用流行的RCU機制…………在這個倡導多核和並發的時代，STL顯得有些落後了。

    當然，STL仍然是非常優秀的庫。記憶體管理、海量資料以及並發的問題，就算不使用STL，在自己實現的庫中也同樣會面臨這些問題。同時，我們也期待多線程環境下的一個標準庫能夠出現，站在巨人的肩上快速的構建應用。