Java效能優化原則：程式碼運算效能、記憶體回收、應用配置（影響Java程式主要原因是垃圾回收，下面會重點介紹這方面）

程式碼層優化：避免過多迴圈巢狀、呼叫和複雜邏輯。

Tomcat調優主要內容如下：

1、增加最大連線數

2、調整工作模式

3、啟用gzip壓縮

4、調整JVM記憶體大小

5、作為Web伺服器時，與Apache整合或Nginx

6、合理選擇垃圾回收演算法

7、儘量使用較新JDK版本

生產配置例項：

<Connectorport="8080"protocol="org.apache.coyote.http11.Http11NioProtocol"                maxThreads="1000"                minSpareThreads="100"                maxSpareThreads="200"                acceptCount="900"                disableUploadTimeout="true"               connectionTimeout="20000"                URIEncoding="UTF-8"                enableLookups="false"                redirectPort="8443"                compression="on"               compressionMinSize="1024"               compressableMimeType="text/html,text/xml,text/css,text/javascript"/>

引數說明：

org.apache.coyote.http11.Http11NioProtocol：調整工作模式為Nio

maxThreads：最大執行緒數，預設150。增大值避免佇列請求過多，導致響應緩慢。

minSpareThreads：最小空閒執行緒數。

maxSpareThreads：最大空閒執行緒數，如果超過這個值，會關閉無用的執行緒。

acceptCount：當處理請求超過此值時，將後來請求放到佇列中等待。

disableUploadTimeout：禁用上傳超時時間

connectionTimeout：連線超時，單位毫秒，0代表不限制

URIEncoding：URI地址編碼使用UTF-8

enableLookups：關閉dns解析，提高響應時間

compression：啟用壓縮功能

compressionMinSize：最小壓縮大小，單位Byte

compressableMimeType：壓縮的檔案型別

Tomcat有三種工作模式：Bio、Nio和Apr，下面簡單瞭解下他們工作原理：

Bio(Blocking I/O)：預設工作模式，阻塞式I/O操作，沒有任何優化技術處理，效能比較低。

Nio(New I/O or Non-Blocking)：非阻塞式I/O操作，有Bio有更好的併發處理效能。

Apr(Apache Portable Runtime，Apache可移植執行庫)：首選工作模式，主要為上層的應用程式提供一個可以跨越多作業系統平臺使用的底層支援介面庫。

tomcat利用基於Apr庫tomcat-native來實現作業系統級別控制，提供一種優化技術和非阻塞式I/O操作，大大提高併發處理能力。但是需要安裝apr和tomcat-native庫。

工作模式原理涉及到了網路I/O模型知識：

阻塞式I/O模型：應用程序呼叫recv函式系統呼叫時，如果等待要操作的資料沒有傳送到核心緩衝區，應用程序將阻塞，不能接收其他請求。反之，核心recv端緩衝區有資料，核心會把資料複製到使用者空間解除阻塞，繼續處理下一個請求。（核心空間(緩衝區)--使用者空間(系統呼叫)）

非阻塞式I/O模型：應用程序設定成非阻塞模式，如果要操作的資料沒有傳送到核心緩衝區，recv系統呼叫返回一個錯誤，應用程序利用輪詢方式不斷檢查此操作是否就緒，如果緩衝區中有資料則返回，I/O操作同時不會阻塞應用程序，期間會繼續處理新請求。

I/O複用模型：阻塞發生在select/poll的系統呼叫上，而不是阻塞在實際的I/O系統呼叫上。能同時處理多個操作，並檢查操作是否就緒，select/epoll函式發現有資料就緒後，就通過實際的I/O操作將資料複製到應用程序的緩衝區中。

非同步I/O模型：應用程序通知核心開始一個非同步I/O操作，並讓核心在整個操作（包括資料複製緩衝區）完成後通知應用程序，期間會繼續處理新請求。

I/O操作分為兩個階段：第一個階段等待資料可用，第二個階段將資料從核心複製到使用者空間。

前三種模型的區別：第一階段阻塞式I/O阻塞在I/O操作上，非阻塞式I/O輪詢，I/O複用阻塞在select/poll或epoll上。第二階段都是一樣的。而非同步I/O的兩個階段都不會阻塞程序。

Java效能問題主要來自於JVM，JVM GC也比較複雜，再調優之前瞭解下相關基礎概念是必要的：

1）JVM記憶體劃分分為年輕代（Young Generation）、老年代（Old Generation）、永久代（Permanent Generation）。

2）年輕代又分為Eden和Survivor區。Survivor區由FromSpace和ToSpace組成。Eden區佔大容量，Survivor兩個區佔小容量，預設比例大概是8:2。

3）堆記憶體（Heap）=年輕代+老年代。非堆記憶體=永久代。

4）堆記憶體用途：存放的是物件，垃圾收集器就是收集這些物件，然後根據GC演算法回收。

5）非堆記憶體用途：JVM本身使用，存放一些類、方法、常量、屬性等。

6）年輕代：新生成的物件首先放到年輕代的Eden區中，當Eden滿時，經過GC後，還存活的物件被複制到Survivor區的FromSpace中，如果Survivor區滿時，會再被複制到Survivor區的ToSpace區。如果還有存活物件，會再被複制到老年代。

7）老年代：在年輕代中經過GC後還存活的物件會被複制到老年代中。當老年代空間不足時，JVM會對老年代進行完全的垃圾回收（Full GC）。如果GC後，還是無法存放從Survivor區複製過來的物件，就會出現OOM（Out of Memory）。

8）永久代：也稱為方法區，存放靜態型別資料，比如類、方法、屬性等。

垃圾回收（GC，Garbage Collection）演算法：

1）標記-清除（Mark-Sweep）

GC分為兩個階段，標記和清除。首先標記所有可回收的物件，在標記完成後統一回收所有被標記的物件。同時會產生不連續的記憶體碎片。碎片過多會導致以後程式執行時需要分配較大物件時，無法找到足夠的連續記憶體，而不得已再次觸發GC。

2）複製（Copy）

將記憶體按容量劃分為兩塊，每次只使用其中一塊。當這一塊記憶體用完了，就將存活的物件複製到另一塊上，然後再把已使用的記憶體空間一次清理掉。這樣使得每次都是對半個記憶體區回收，也不用考慮記憶體碎片問題，簡單高效。缺點需要兩倍的記憶體空間。

3）標記-整理（Mark-Compact）

也分為兩個階段，首先標記可回收的物件，再將存活的物件都向一端移動，然後清理掉邊界以外的記憶體。此方法避免標記-清除演算法的碎片問題，同時也避免了複製演算法的空間問題。

一般年輕代中執行GC後，會有少量的物件存活，就會選用複製演算法，只要付出少量的存活物件複製成本就可以完成收集。而老年代中因為物件存活率高，沒有額外過多記憶體空間分配，就需要使用標記-清理或者標記-整理演算法來進行回收。

垃圾收集器：

1）序列收集器（Serial）

比較老的收集器，單執行緒。收集時，必須暫停應用的工作執行緒，直到收集結束。

2）並行收集器（Parallel）

多條垃圾收集執行緒並行工作，在多核CPU下效率更高，應用執行緒仍然處於等待狀態。

3）CMS收集器（Concurrent Mark Sweep）

CMS收集器是縮短暫停應用時間為目標而設計的，是基於標記-清除演算法實現，整個過程分為4個步驟，包括：

• 初始標記（Initial Mark）
• 併發標記（Concurrent Mark）
• 重新標記（Remark）
• 併發清除（Concurrent Sweep）

其中，初始標記、重新標記這兩個步驟仍然需要暫停應用執行緒。初始標記只是標記一下GC Roots能直接關聯到的物件，速度很快，併發標記階段是標記可回收物件，而重新標記階段則是為了修正併發標記期間因使用者程式繼續運作導致標記產生變動的那一部分物件的標記記錄，這個階段暫停時間比初始標記階段稍長一點，但遠比並發標記時間段。

由於整個過程中消耗最長的併發標記和併發清除過程收集器執行緒都可以與使用者執行緒一起工作，所以，CMS收集器記憶體回收與使用者一起併發執行的，大大減少了暫停時間。

4）G1收集器（Garbage First）

G1收集器將堆記憶體劃分多個大小相等的獨立區域（Region），並且能預測暫停時間，能預測原因它能避免對整個堆進行全區收集。G1跟蹤各個Region裡的垃圾堆積價值大小（所獲得空間大小以及回收所需時間），在後臺維護一個優先列表，每次根據允許的收集時間，優先回收價值最大的Region，從而保證了再有限時間內獲得更高的收集效率。

G1收集器工作工程分為4個步驟，包括：

• 初始標記（Initial Mark）
• 併發標記（Concurrent Mark）
• 最終標記（Final Mark）
• 篩選回收（Live Data Counting and Evacuation）

初始標記與CMS一樣，標記一下GC Roots能直接關聯到的物件。併發標記從GC Root開始標記存活物件，這個階段耗時比較長，但也可以與應用執行緒併發執行。而最終標記也是為了修正在併發標記期間因使用者程式繼續運作而導致標記產生變化的那一部分標記記錄。最後在篩選回收階段對各個Region回收價值和成本進行排序，根據使用者所期望的GC暫停時間來執行回收。

瞭解了JVM基礎知識，下面配置下相關Java引數，將下面一段放到catalina.sh裡面：

注意：不是JVM記憶體設定越大越好，具體還是根據專案物件實際佔用記憶體大小而定，可以通過Java自帶的分析工具來檢視。如果設定過大，會增加回收時間，從而增加暫停應用時間。

部落格地址：http://lizhenliang.blog.51cto.com

QQ群：323779636（Shell/Python運維開發群）

gzip壓縮作用：節省伺服器流量和提高網站訪問速度。客戶端請求伺服器資源後，伺服器將資原始檔壓縮，再返回給客戶端，由客戶端的瀏覽器負責解壓縮並瀏覽。

使用Apache與Tomcat整合，因為Tomcat處理靜態檔案能力遠不足Apache，因此讓Apache來處理靜態檔案，Tomcat處理動態jsp檔案，可以有效提高處理速度。

在叢集架構下，會涉及到一個問題，怎麼儲存Session？

TomcatSessionID持久化三種方法：

   Session粘性：通過瀏覽器Cookie繫結SessionID，通過sticky模式將同一Session請求分配到同一Tomcat上。

   Session複製：Tomcat通過廣播形式將Session同步到其他Tomcat節點，並且Linux下要手動開啟開放廣播地址。不易後端節點過多

 Session儲存資料庫（memcache、redis）：將SessionID儲存在共享的資料庫中。

OOM（Out of Memory）異常常見有以下幾個原因：

1）老年代記憶體不足：java.lang.OutOfMemoryError:Javaheapspace

2）永久代記憶體不足：java.lang.OutOfMemoryError:PermGenspace

3）程式碼bug，佔用記憶體無法及時回收。

前兩種情況通過加大記憶體容量，可以得到解決。如果是程式碼bug，就要通過jstack、jmap、jstat自帶的工具分析問題，定位到相關程式碼，讓開發解決。