當調用第一個方法時，給第一個方法劃分一段棧幀空間並壓入棧內。當這個方法執行完了將這個方法對應的棧幀出棧也就是釋放這個方法所佔用的內存。這就是棧和棧幀之間關係，一個棧內有沒有可能多個棧幀存在？有的，調用方法1，方法1間接調用方法2，爲方法2調用一塊內存入棧，方法2又調用了方法3（尾遞歸）。。。方法3調用結束就把棧幀3內存釋放掉。。。。
如下活動棧幀就是棧頂部的正在執行的方法
棧內存就是一次次方法調用產生的棧幀內存，棧幀內存在每次方法結束後被彈出棧自動回收掉，不需要垃圾回收管理棧內存。垃圾回收只回收堆內存中無用對象。棧內存可通過運行代碼時虛擬機參數指定，棧內存劃的越大反而讓線程數變少。因爲物理內存大小一定的，比如一個線程使用了1M棧內存，總共物理內存有500M，理論上有500個同時運行。如果對每個線程的棧內存設置了2M，只能同時運行250個線程。所以棧內存不是分配越大越好，劃分大了只能更多次進行方法遞歸調用不會增強運行效率反而影響到線程數目變少，一般採用系統默認棧內存大小就可以
方法的局部變量存儲在棧中（線程私有），類的static成員變量在方法區（線程共享）
x變量是方法內的局部變量，我們說一個線程對應一個棧，線程內每次方法調用會產生一個新的棧幀，如下線程不會產生安全問題
如下不加線程保護的話會產生安全問題
如下只有第一個線程安全
棧幀過多：方法的遞歸調用沒有設置正確的計數條件導致遞歸爆棧。棧幀過大（很少出現）：棧幀裏都是些局部變量，方法參數，佔用的內存都很小（一個int變量4字節，默認棧大小1M左右）
如下設置Xss棧大小256k，比默認小。如上代碼執行減少到5000多次
兩個類循環引用導致將java對象解析爲json字符串數據StackOverflowError
如下線程診斷
top命令只能定位到進程，無法定位到線程
本地方法：不是由java編寫的方法。java不能與操系底層打交道，需要C/C++本地方法與os底層api打交道。java可間接通過本地方法調用底層功能。本地方法棧就是給本地方法提供的內存空間
程序計數器，虛擬機棧（只要局部變量不同逃逸出方法的作用範圍就是線程安全的），本地方法棧都是線程私有的。堆和方法區是線程共享。堆中不再被引用的對象（這對象沒人再使用了，但是如果不斷產生對象有人用就不能作爲垃圾）當成垃圾進行回收釋放空閒的內存，不至於讓內存被創建的對象撐爆
方法區：存儲了類結構相關信息
2.分佈式事務
分佈式事務是個問題就是無法用本地數據庫控制
不能因爲網絡問題導致通信失敗，分佈式事務控制到底控制到什麼程度，當出現網絡問題時是數據不一致，某個服務不可用，要控制到什麼程度
一致性hash 算法：假設有三臺緩存服務器S0，S1，S2，有三萬張圖片進行緩存，最好能均勻緩存到服務器上分擔緩存壓力。簡單做法對緩存下來的鍵進行哈希計算得到整數，再用緩存服務器數量對這個值取模計算，用取模產生的餘數來決定數據應該緩存在哪臺服務器上。對同一個圖片名稱做相同哈希計算時得到hash值不變的，所以當需要訪問圖片時再次對圖片名稱進行hash計算和取模計算就能知道圖片存放在哪臺服務器上，只要在這臺服務器上查找圖片就行
底層內存上存儲是hash算法，用到緩存redis就用到大量hash（好處：無限存數據，查找效率高）。直接尋址法一次查找得結果（只這個一個，最快）
hash算法寫的好就能平均分配
爲什麼二叉搜索樹（大的放右邊，小的放左邊，每個節點分裂出來最多兩個節點）很少在數據結構存儲裏用（因爲瘦高）
如下平衡二叉樹（AVL Tree，瘦高）左子樹和右子樹都是平衡二叉樹，而且左子樹和右子樹深度之差絕對值不會超過1(左旋和右旋)
如下innodb引擎和磁盤交互時一頁加載大小16kb
每次加載數據只加載一個節點數據，每次和磁盤交互時16kb，但只能拿到20b
關係型數據庫鼻主：B-Tree
Btree中查找根節點io一次，B+tree查找節點都需要io三次（這樣穩定），B+tree基於索引的排序能力強
