系統優化怎麼作-JVM優化之開篇

前言

在上一期Tomcat優化中，針對JVM相關主要參數作過必定說明，這一期主要介紹進行一些概念及經驗。後面分章節去講述相關工具的基本使用。

優化優先級

總體來說，系統優化應先優化架構及代碼，來解決具體功能點效率問題。最後經過JVM監控工具來發現一些隱藏較爲深刻的問題。

相關情形

• 內存佔用並不斷增長, 系統壓力大狀況下Full GC頻繁，系統出現卡頓
• 線程出現大量等待及死鎖, CPU使用率太高, 系統響應慢
• 堆（heap）內存不足或類加載致使JVM Crash,系統宕機

出現以上狀況，就得使用工具分析JVM來肯定問題

JVM內存模型

JDK1.7及如下

JDK1.8下，PermGen替換成Vm MetaSpace

Heap域

• 全局被全部線程分享
• 存全部對象及集合對象

方法域

• 全局被全部線程分享
• 存全部類的結構定義包含屬性，方法及構造函數等

Thread1.N

• 本地私有棧，一個線程一個棧
• 保持着全部在Heap域的對象引用（4byte長度）
• 存儲本地局部變量的存儲（基礎數據類型)，程序運行狀態，方法返回值

內存泄漏的分類

• 堆內存泄漏 - 比較常見
• 持久代內存泄漏
• 棧內存泄漏
• 系統資源內存泄漏 -比較常見

線程相關知識

JVM線程狀態遷移

線程狀態

• 初始化（New）：初期建立,啓動後則進入可執行狀態
• 可執行狀態（Runnable）: 只要獲取CPU時間，則開始執行
• 運行狀態（Running）: 正在使用CPU執行

• 阻塞狀態（Bloked）

  • 等待阻塞(wait)
  • 同步阻塞(synchronized)
  • 睡眠阻塞(sleep)
  • Join阻塞: 等待join子線程結束後，主線程才能執行，將異步執行的線程合併爲同步的線程
• 結束狀態： 線程執行完畢或者異常退出

性能監控關注點

• 系統線程總數
• 死鎖線程 須要優先解決

• 線程Bloked總數數量

  線程Bloked多的狀況下，考慮對待處理數據進行分片,進行多通道,多線程處理提升系統性能
  若是系統處理慢，但CPU佔用一直很低，就須要梳理系統處理流程，串行處理該並行處理，並行處理流程提升併發來解決。

線程死鎖

當兩個或者多個線程嘗試獲取其餘資源的鎖，而每一個線程又陷入無限等待其餘資源鎖的釋放（相互等待），除非一個用戶的進程被終止。

幾個死鎖場景

• 兩個線程相互調用Thread.join(), 致使互相等待同步結束。

慎用線程join操做

• 當兩個線程使用嵌套的同步塊時，一個線程佔用了另外一個線程的必需的鎖，互相等待時被阻塞，就有可能出現死鎖。 也可能多個線程造成環狀鎖，好比線程A等待線程B，線程B等待線程C，線程C等待線程A。線程A爲了檢測死鎖，它須要遞進地檢測全部被B請求的鎖。從線程B所請求的鎖開始，線程A找到了線程C，發現線程C請求的鎖被線程A本身持有着。這是它就知道發生了死鎖。

• MySql死鎖

MySql中兩個線程同時對兩條記錄作先讀後寫操做

避免死鎖

• 安全狀態

找到一個分配資源的序列能讓全部進程都順利完成

• 銀行家算法

採用預分配策略檢查分配完成時系統是否處在安全狀態

檢測死鎖

• VisualVM（或其餘工具）

監控線程狀態，若是出現死鎖獲得相關代碼位置

• 死鎖定理化間資源分配圖

利用死鎖定理化間資源分配圖來分析死鎖的存在
參見如下資料:
https://www.coursera.org/lect...

總結

本章主要講了一些核心知識，主要爲了讓你們瞭解系統優化到底優化和解決什麼問題，什麼是優化的目標。後續章節會講到tomcat的JMX配置，VisualVM，Tprofile等工具的使用。

思考題

JVM線程有哪些狀態,這些線程大多處於什麼樣的狀態分佈, 咱們能夠稱系統運行是健康的。