通俗易懂理解JAVA虛擬機（二）——JVM總體結構深度解析
通俗易懂理解JAVA虛擬機（二）——JVM總體結構深度解析，JVM內存參數設置實戰
已有足夠多的優秀的介紹JVM內存模型的文章，在這裏再也不過多贅述直接上圖。本文主要詳解大型電商互聯網公司如何設置JVM的內存參數。
一 . JVM總體結構及內存模型
2、JVM內存參數設置
Spring Boot程序的JVM參數設置格式(Tomcat啓動直接加在bin目錄下catalina.sh文件裏)：
1java ‐Xms2048M ‐Xmx2048M ‐Xmn1024M ‐Xss512K ‐XX:MetaspaceSize=256M ‐XX:MaxMetaspaceSize=256M ‐jar microservice‐eureka‐server.jar
StackOverflowError示例：
java
結論：-Xss設置越小count值越小，說明一個線程棧裏能分配的棧幀就越少，可是對JVM總體來講能開啓的線程數會更多
JVM內存參數大小該如何設置？
JVM參數大小設置並無固定標準，須要根據實際項目狀況分析，給你們舉個例子web
日均百萬級訂單交易系統如何設置JVM參數服務器
一天百萬級訂單這個絕對是如今頂尖電商公司交易量級，對於這種量級的系統咱們該如何設置JVM參數了？svg
咱們能夠試着估算下，其實日均百萬訂單主要也就是集中在當日的幾個小時生成的，咱們假設是三小時，也就是每秒大概生成100單左右。性能
這種系統咱們通常至少要三四臺機器去支撐，假設咱們部署了四臺機器，也就是每臺每秒鐘大概處理完成25單左右，往上毛估每秒處理30單吧。spa
也就是每秒大概有30個訂單對象在堆空間的新生代內生成，一個訂單對象的大小跟裏面的字段多少及類型有關，好比int類型的訂單id和用戶id等字段，double類型的訂單金額等，int類型佔用4字節，double類型佔用8字節，初略估計下一個訂單對象大概1KB左右，也就是說每秒會有30KB的訂單對象分配在新生代內。操作系統
真實的訂單交易系統確定還有大量的其餘業務對象，好比購物車、優惠券、積分、用戶信息、物流信息等等，實際每秒分配在新生代內的對象大小應該要再擴大幾十倍，咱們假設30倍，也就是每秒訂單系統會往新生代內分配近1M的對象數據，這些數據通常在訂單提交完的操做作完以後基本都會成爲垃圾對象。線程
咱們通常線上服務器的配置用得較多的就是雙核4G或4核8G，若是咱們用雙核4G的機器，由於服務器操做系統包括一些後臺服務自己可能就要佔用1G多內存，也就是說給JVM進程最多分配2G多點內存，刨開給方法區和虛擬機棧分配的內存，那麼堆內存可能也就能分配到1G多點，對應的新生代內存最後可能就幾百M，那麼意味着沒過幾百秒新生代就會被垃圾對象撐滿而出發minor gc，這麼頻繁的gc對系統的性能仍是有必定影響的。3d
若是咱們選擇4核8G的服務器，就能夠給JVM進程分配四五個G的內存空間，那麼堆內存能夠分到三四個G左右，因而能夠給新生代至少分配2G，這樣算下差很少須要半小時到一小時才能把新生代放滿觸發minor gc，這就大大下降了minor gc的頻率，因此通常咱們線上服務器用得較多的仍是4核8G的服務器配置。server
若是系統業務量繼續增加那麼能夠水平擴容增長更多的機器，好比五臺甚至十臺機器，這樣每臺機器的JVM處理請求能夠保證在合適範圍，不至於壓力過大致使大量的gc。
有人可能有疑問說雙核4G的服務器好像也夠用啊，無非就是minor gc頻率稍微高一點呀，不是說minor gc對系統的影響不是特別大嗎，我成本有限，只能用這樣的服務器啊。
其實若是系統業務量比較平穩也能湊合用，若是常常業務量可能有個幾倍甚至幾十倍的增加，好比時不時的搞個促銷秒殺活動什麼的，那咱們思考下會不會有什麼問題。
假設業務量暴增幾十倍，在不增長機器的前提下，整個系統每秒要生成幾千個訂單，以前每秒往新生代裏分配的1M對象數據可能增加到幾十M，並且由於系統壓力驟增，一個訂單的生成不必定能在1秒內完成，可能要幾秒甚至幾十秒，那麼就有不少對象會在新生代裏存活幾十秒以後纔會變爲垃圾對象，若是新生代只分配了幾百M，意味着一二十秒就會觸發一次minor gc，那麼頗有可能部分對象就會被挪到老年代，這些對象到了老年代後由於對應的業務操做執行完畢，立刻又變爲了垃圾對象，隨着系統不斷運行，被挪到老年代的對象會愈來愈多，最終可能又會致使full gc，full gc對系統的性能影響仍是比較大的。
若是咱們用的是4核8G的服務器，新生代分配到2G以上的水平，那麼至少也要幾百秒纔會放滿新生代觸發minor gc，那些在新生代即使存活幾十秒的對象在minor gc觸發的時候大部分已經變爲垃圾對象了，均可以被及時回收，基本不會被挪到老年代，這樣能夠大大減小老年代的full gc次數。