出處:https://dwz.cn/tQe4fLeD
<code>e.printStackTrace/<code>會導致鎖死?這僅僅是打印啊,怎麼可能?
先別驚呼不可能,且聽我細細道來。
先看截圖1:
注意右下角區域,紅框部分。這塊內存是什麼呢?非堆!那麼,左邊是代碼緩存區內存,右邊紅框就是字符串池,常量,基本類型數據的內存區。然後呢?已經滿了。什麼原因呢?
<code>e.printStackTrace/<code>!
滿了的後果呢?整個web服務,訪問之後,沒響應了,就當是卡死掉了。
再來看截圖2:
看看有多少web的請求線程,被卡住在打印這一步!原因呢?要打印字符串輸出到控制檯上,那你字符串常量池所在的內存塊要有空間啊。然而,因為e.printStackTrace 語句要產生的字符串記錄的是堆棧信息,太長太多,內存被填滿了!注意 上面代碼語句:4208行!
來看圖3:
沒毛病,沒沒事兒找事兒冤枉誰。就是這句代碼惹的禍!當然,我承認,被 try 住的代碼本身就有問題,導致很多調用都會拋異常。
那麼,讓我們再來理理整個事件產生的經過:
<code>-> 短時間內大量請求訪問此接口
-> 代碼本身有問題,很多情況下拋異常
-> e.printStackTrace 來打印異常到控制檯
-> 產生錯誤堆棧字符串到字符串池內存空間
-> 此內存空間一下子被佔滿了
-> 開始在此內存空間產出字符串的線程還沒完全生產完整,就沒空間了
-> 大量線程產出字符串產出到一半,等在這兒(等有內存了繼續搞啊)
-> 相互等待,等內存,鎖死了,整個應用掛掉了。
/<code>
總結
總結當然重要,有3點:
1.代碼質量啊親,代碼不拋異常咱不就能愉快的繼續浪麼?
2.不要使用<code>e.printStackTrace/<code>啊,這玩意兒,在項目發佈後,除過不斷的刷控制檯,並沒用什麼卵用啊,您到是用log對象輸出到日誌文件裡面啊。
3.推及開來,在java中,會產生大量字符串的方法,使用時,一定得悠著點,別一不小心撐到肚子(字符串池所屬的那麼點非堆內存空間),撐到肚子了,會死的啊。
———— e n d ————
微服務、高併發、JVM調優、面試專欄等20 大進階架構師專題請關注公眾號【Java進階架構師】後在菜單欄查看。
閱讀更多 Java進階架構師 的文章