案例1
情況：選用64位的JDK，堆大小固定12GB
問題：網站經常是定期，長時間失去響應，GC太長，回收12GB的堆，一次Full GC停頓14秒
解決方式：1.通過64位JDK使用大內存。2.使用若干32位虛擬機建立集羣使用資源。
第一種：控制Full GC頻率，則需要大多數對象的生存時間不應該太長。大部分對象都是 朝生夕滅，才能保證超大堆能正常使用而沒有Full GC
第二種：在一臺物理機上，啓動多個服務應用，通過nginx負載均衡處理請求，每臺服務平均分配12GB大內存。
案例2
情況：電子考試系統，客戶端實時從服務器接受考試數據，4GB內存，1.6GB給java，Window32系統
問題：服務端不定時拋出內存溢出異常，Window32，限制2GB內存，劃分1.6GB給java堆（在32位windows的機器上，堆最大可以達到1.4G至1.6G），其他只有0.4GB，垃圾收集時，虛擬機雖然會對
Direct Memory進行回收，但是它不會發現空間不足就通知收集器進行垃圾回收，它要等到老年代滿了後
Full GC纔會清理這些內存，否則就要等到內存溢出拋出異常。
解決方式：調整-XX：MaxDirectMemorySize
案例3
情況：業務每10分鐘加載一個80MB的數據文件到內存進行分析，100萬個HashMap<Long,Long>
問題：分析，一個HashMap：Long(24B)*2+Entry(32B)+HashMap Ret(8B)=88B。
Long：8BMarkWord+8B的Klass指針+8B數據=24B
MapEntry：16B對象頭+8Bnext字段+4B的int類型hash字段=32B
對齊：4B
但其實他只要兩個Long16B就行。
解決方式：1.去掉Survivor空間（-XX:SurvivorRatio=65536,-XX:MaxTenuringThreshold=0）,讓新生代的對象第一次Minor GC就進入老年代，治標不治本。
2.修改這個數據結構
