摘要：最近線上一個應用出現(xiàn)了一個無法加載，卡住了的問題。因此確定問題，是開發(fā)新上線的代碼線程棧用的太大，導致原先設置的不足，需要調大。最后把預發(fā)布和生產環(huán)境的調大后，問題解決。參考資料優(yōu)化系列之一調整的大小

最近線上一個應用出現(xiàn)了一個 tomcat 無法加載，卡住了的問題。引起該問題的原因是開發(fā)同事的一個老項目新增了一些功能，需要進行上線，首先發(fā)布到預發(fā)布環(huán)境后，重起 tomcat，發(fā)現(xiàn)出現(xiàn)如下現(xiàn)象：

Oct 27, 2014 10:31:14 AM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-bio-9009"]
Oct 27, 2014 10:31:14 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 586 ms
Oct 27, 2014 10:31:14 AM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Oct 27, 2014 10:31:14 AM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.40
10:31:20,011[INFO]MLog:80 MLog clients using log4j logging.

即 tomcat 的日志顯示，走到 MLog clients using log4j logging 這就不往下走了。

雖然我的預發(fā)布環(huán)境沒有做任何變更，但是為了穩(wěn)妥起見，還是把代碼在生產集群中的其中一臺服務器發(fā)布下，結果表現(xiàn)的現(xiàn)象是一樣的，還是加載不成功。

但是開發(fā)同事又說在測試環(huán)境是能正常加載的，為了證明不是環(huán)境問題，所以讓開發(fā)同事先回滾代碼，回滾后，再發(fā)布，能正常加載，所以我讓開發(fā)同事排查下代碼，看是不是代碼有問題，因為開發(fā)同事上線了兩個新功能，所以我讓其把功能拆開了上線發(fā)布，結果是上線其中一個功能能正常加載，上線另外一個不能正常加載，那根據(jù)這個可以判斷是另外一個功能的代碼問題了。但是結果一天的排查，還是不能確定到底是什么問題。同時開放同事堅決表示測試和開發(fā)都沒有問題，為什么就生產有問題。所以只好繼續(xù)從環(huán)境入手了。

我最后讓開發(fā)把測試環(huán)境的 tomcat 配置發(fā)給我看下，看是否不一致（最后才查看 tomcat 配置，是因為我們的環(huán)境 tomcat 類似的一直都是測試，預發(fā)布，生產保持一致的，所以當時沒有想到這方面）。最后一對比發(fā)現(xiàn)，tomcat 配置的 -Xss 這個值不一樣，預發(fā)布和生產的是設置的 256k，而測試環(huán)境是設置的 512k，最后把測試環(huán)境的該值調小到與預發(fā)布環(huán)境一致。重顯了該現(xiàn)象。因此確定問題，是開發(fā)新上線的代碼線程棧用的太大，導致原先設置的不足，需要調大。最后把預發(fā)布和生產環(huán)境的 -Xss 調大后，問題解決。

  
注：運維問題真是不能想當然，要一步步的把所有的差異都對比，然后一一的修正測試。

參考資料：

JVM優(yōu)化系列之一（-Xss調整Stack Space的大?。?/p>