1)多數的Java應用不需要在服務器上進行GC優化；
2)多數導致GC問題的Java應用，都不是因為我們參數設置錯誤，而是代碼問題；
3)在應用上線前，先考慮將JVM參數設置到最優；
4)減少對象創建的數量；
5)減少全局變量和大對象；
6)GC優化是最后不得已才使用的手段，在實際應用中，分析GC情況優化代碼比優化GC參數要多得多；
通過看監控中的jvm是否有fgc，頻繁fgc才需要優化（頻繁fgc需要抓緊改配置）
1)JDK的命令行工具
Sun JDK監控和故障處理命令有jps、jstat、jmap、jhat、jstack、jinfo
jps(虛擬機進程狀況工具)：顯示指定系統內所有的HotSpot虛擬機進程。 jstat(虛擬機統計信息監視工具)：用于監視虛擬機運行時狀態信息的命令，它可以顯示出虛擬機進程中的類裝載、內存、垃圾收集、JIT編譯等運行數據。 jinfo(Java配置信息工具)：jinfo的作用是實時地查看和調整虛擬機各項參數。
jmap(Java內存映像工具)：dump堆到文件，可用于對文件的分析。
jhat(虛擬機堆轉儲快照分析工具)：jhat命令與jmap搭配使用，來分析jmap生成的堆 轉儲快照。jhat內置了一個微型的HTTP/HTML服務器，生成dump文件的分析結果后，可以在瀏覽器中查看。
jstack(Java堆棧跟蹤工具)：jstack命令用于生成虛擬機當前時刻的線程快照。線程快照就是當前虛擬機內每一條線程正在執行的方法堆棧 的集合，生成線程快照的主要目的是定位線程出現長時間停頓的原因，如線程間死鎖、死循 環、請求外部資源導致的長時間等待等都是導致線程長時間停頓的常見原因。線程出現停頓 的時候通過jstack來查看各個線程的調用堆棧，就可以知道沒有響應的線程到底在后臺做些 什么事情，或者等待著什么資源。
2)JConsole
Jconsole（Java Monitoring and Management Console）是從java5開始，在JDK中自帶的java監控和管理控制臺，用于對JVM中內存，線程和類等的監控，是一個基于JMX（java management extensions）的GUI性能監測工具。jconsole使用jvm的擴展機制獲取并展示虛擬機中運行的應用程序的性能和資源消耗等信息。
概覽：包括堆內存使用情況、線程、類、CPU使用情況四項信息的曲線圖。
3)VisualVM
VisualVM（All-in-One Java Troubleshooting Tool）是功能最強大的運行監視和故障處理程序之一，曾經在很長一段時間內是Oracle官方主力發展的虛擬機故障處理工具。
相比一些第三方工具，VisualVM有一個很大的優點：不需要被監視的程序基于特殊Agent去運行，因此它的通用性很強，對應用程序實際性能的影響也較小，使得它可以直接應用在生產環境中。
Visual GC 是常常使用的一個功能，需要通過插件按照，可以明顯的看到年輕代、老年代的內存變化，以及gc頻率、gc的時間等！
觸發 java.lang.OutOfMemoryError:最常見的原因就是應用程序需要的堆空間需要的是大的，但是 JVM 提供的卻是小的，從而導致內存溢出。這個解決方法就是提供大的堆空間即可。
除此之外還有復雜的原因：內存泄露。特定的編程錯誤會導致你的應用程序不停的消耗更多的內存，每次使用有內存泄漏風險的功能就會留下一些不能被回收的對象到堆空間中，隨著時間的推移，泄漏的對象會消耗所有的堆空間，最終觸發java.lang.OutOfMemoryError: Java heap space 錯誤。
1.確保有足夠的堆空間來正常運行你的應用程序，在 JVM 的啟動配置中增加如下配置：-Xmx1024m。
2.流量/數據量峰值：應用程序在設計之初均有用戶量和數據量的限制，某一時刻，當用戶數量或數據量突然達到一個 峰 值 ， 并 且 這 個 峰 值 已 經 超 過 了 設 計 之 初 預 期 的 閾 值 ， 那 么 以 前 正 常 的 功 能 將 會 停 止 ， 并 觸 發java.lang.OutOfMemoryError
3.Java heap space 異常解決方案，如果你的應用程序確實內存不足，增加堆內存會解決 GC overhead limit 問題，就如下面這樣，給你的應用程序 1G 的堆內存：java -Xmx1024m com.yourcompany.YourClass。
官方微信
官方抖音
京公網安備 11030102010736號