SOFE之stackoverflowError

首先stackoverflowError是錯誤，不是異常。
最簡單的出發SOFE的操作，無限循環遞歸調用：

錯誤提示：

棧中壓入了太多的方法給撐爆了，棧大小根據平臺有默認值，linux內核的一般是1024k，win系統默認是0。

複習一下java異常的體系結構：

查看SOFE的的繼承樹：屬於虛機機error

oom也是虛擬機錯誤。

OOM之java heap space

簡單理解：堆內存不夠用了。

觸發代碼如下，但是因爲jvm在win平臺上默認最大堆空間是內存的四分之一，所以很難撐爆，需要手動調小一點（10m）。

string的方法intern：https://blog.csdn.net/u011635492/article/details/81048150
錯誤效果：

直接new 字節數組，也可以，方法很多。

OOM之GC overhead limit exceeded

大量的資源被消耗來做垃圾回收，有用的工作只佔很少的一部分。
代碼演示：不斷往list中添加string（不重複）

爲了觸發效果調整jvm參數：堆大小10m，降低直接內存的大小爲5m。

運行效果：運行幾秒之後，會觸發gc overhead的異常。

可以看到爆發異常前產生了full gc，回收前後的young區大小差別不大2047—2047.出現了收不動的現象，老年區也是同樣的現象。

OOM之Direct buffer memoery

這個錯誤跟元空間有關係，元空間使用的是本地內存：

這個錯誤，意思是把你的直接內存都幹翻了！
這個故障結合2種技術出現：netty底層的nio技術。

那麼如何查看分配的直接內存的情況呢？在rt.jar包裏面。

做一個測試，針對16g電腦，直接電腦能利用的有：

內存分配模型：

觸發Direct buffer memoery OOM異常的代碼如下，需要配置一下vm參數：

運行效果：

會發現最後一次full gc收不動了，一般做nio程序的時候經常出現這個異常。這個異常反映了你是否知道nio。

OOM之unable to create new native thread

不能創建更多新的本地線程了。高併發環境下容易觸發這個錯，因爲高併發往往需要創建多線程。
因爲一個系統中的線程數是有上限的。超過上限就報錯誤。
這個異常是一個非常好的案例作爲回答面試官的“說一下你的記憶深刻的故障”。

觸發代碼：

linux上試運行，注意如果帶包名的java文件，需要"-d ."這種參數。

沒有消息就是編譯成功了。運行需要帶包名：

會發現大約在1024個以內就拋出異常了。1024是理論數字，linux進程本身句柄也需要一些線程。