注意右下角區域，紅框部分。這塊記憶體是什麼呢？
非堆！那麼，左邊是代碼緩存區記憶體，右邊紅框就是字元串池，常量，基本類型資料的記憶體區。
然後呢？已經滿了。什麼原因呢？e.printStackTrace()！
滿了的後果呢？整個web服務，通路之後，沒響應了，就當是卡死掉了。
再來看截圖2：
看看有多少web的請求線程，被卡住在列印這一步！
原因呢？
要列印字元串輸出到控制台上，那你字元串常量池所在的記憶體塊要有空間啊。
然而，因為 e.printStackTrace()語句要産生的字元串記錄的是堆棧資訊，太長太多，記憶體被填滿了！注意 上面代碼語句：4208行！
來看圖3：
沒毛病，沒沒事兒找事兒冤枉誰。就是這句代碼惹的禍！當然，我承認，被 try 住的代碼本身就有問題，導緻很多調用都會抛異常。
那麼，讓我們再來理理整個事件産生的經過：
短時間内大量請求通路此接口
-> 代碼本身有問題，很多情況下抛異常
-> e.printStackTrace() 來列印異常到控制台
-> 産生錯誤堆棧字元串到字元串池記憶體空間
-> 此記憶體空間一下子被占滿了
-> 開始在此記憶體空間産出字元串的線程還沒完全生産完整，就沒空間了
-> 大量線程産出字元串産出到一半，等在這兒（等有記憶體了繼續搞啊）
-> 互相等待，等記憶體，鎖死了，整個應用挂掉了。
綜上，這就是 e.printStackTrace() 引發的血案。
總結當然重要，有3點：
1，代碼品質啊親，代碼不抛異常咱不就能愉快的繼續浪麼？
2，不要使用 e.printStackTrace() 啊，這玩意兒，在項目釋出後，除過不斷的刷控制台，并沒用什麼卵用啊，您到是用 log 對象輸出到日志檔案裡面啊。
3，推及開來，在java中，會産生大量字元串的方法，使用時，一定得悠着點，别一不小心撐到肚子（字元串池所屬的那麼點非堆記憶體空間），撐到肚子了，會死的啊 。