一、tomcat的優化
Tomcat優化其實就是對server.xml優化（開戶線程池，調整http connector參數）
executor="tomcatThreadPool" // 開啟線程池
protocol="org.apache.coyote.http11. Http11AprProtocol" //開啟Apr協議，需要安裝Apr支持 (ip -> mac ip處於第三層,通過IP提供第二層mac)
enableLookups="false" // 關閉反向查詢
compression="on" compressionMinSize="4096" // 開啟靜態文件壓縮
noCompressionUserAgents="gozilla, traviata" //開啟靜態文件壓縮
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain,application/json,application/x-javascript" //開啟靜態文件壓縮
二、對catalina.sh優化JVM
Tomcat路徑\bin\catalina.sh
平常在運行使用系統經常會報內存溢出的錯誤，內存溢出也叫OOM 會在catalina.sh加入
set JAVA_OPTS=-server -Xms1024m -Xmx2048m -XX:PermSize=256m -XX:MaxPermSize=512m // -Xms=-Xmx=服務器內存*70%
大對象出現在年輕代很可能擾亂年輕代 GC，並破壞年輕代原有的對象結構。因為嘗試在年輕代分配大對象，很可能導致空間不足，為了有足夠的空間容納大對象，JVM 不得不將年輕代中的年輕對象挪到年老代
因為大對象占用空間多，所以可能需要移動大量小的年輕對象進入年老代，這對 GC 相當不利。盡可能避免使用短命的大對象。可以使用參數-XX:PetenureSizeThreshold 設置大對象直接進入年老代的閾值。當對象的大小超過這個值時，將直接在年老代分配。參數-XX:PetenureSizeThreshold 只對串行收集器和年輕代並行收集器有效，並行回收收集器不識別這個參數。
嘗試使用大的內存分頁
CPU 是通過尋址來訪問內存的。32 位 CPU 的尋址寬度是 0~0xFFFFFFFF ，計算后得到的大小是 4G，也就是說可支持的物理內存最大是 4G。但在實踐過程中，碰到了這樣的問題，程序需要使用 4G 內存，而可用物理內存小於 4G，導致程序不得不降低內存占用。為了解決此類問題，現代 CPU 引入了 MMU（Memory Management Unit 內存管理單元）。MMU 的核心思想是利用虛擬地址替代物理地址，即 CPU 尋址時使用虛址，由 MMU 負責將虛址映射為物理地址。MMU 的引入，解決了對物理內存的限制，對程序來說，就像自己在使用 4G 內存一樣。內存分頁 (Paging) 是在使用 MMU 的基礎上，提出的一種內存管理機制。它將虛擬地址和物理地址按固定大小（4K）分割成頁 (page) 和頁幀 (page frame)，並保證頁與頁幀的大小相同。這種機制，從數據結構上，保證了訪問內存的高效，並使 OS 能支持非連續性的內存分配。在程序內存不夠用時，還可以將不常用的物理內存頁轉移到其他存儲設備上，比如磁盤，這就是大家耳熟能詳的虛擬內存
在 Solaris 系統中，JVM 可以支持 Large Page Size 的使用。使用大的內存分頁可以增強 CPU 的內存尋址能力，從而提升系統的性能。
java –Xmx2506m –Xms2506m –Xmn1536m –Xss128k –XX:++UseParallelGC
–XX:ParallelGCThreads=20 –XX:+UseParallelOldGC –XX:+LargePageSizeInBytes=256m
–XX:+LargePageSizeInBytes：設置大頁的大小。
過大的內存分頁會導致 JVM 在計算 Heap 內部分區（perm, new, old）內存占用比例時，會出現超出正常值的划分，最壞情況下某個區會多占用一個頁的大小。
使用非占有的垃圾回收器
為降低應用軟件的垃圾回收時的停頓，首先考慮的是使用關注系統停頓的 CMS 回收器，其次，為了減少 Full GC 次數，應盡可能將對象預留在年輕代，因為年輕代 Minor GC 的成本遠遠小於年老代的 Full GC。
java –Xmx3550m –Xms3550m –Xmn2g –Xss128k –XX:ParallelGCThreads=20
–XX:+UseConcMarkSweepGC –XX:+UseParNewGC –XX:+SurvivorRatio=8 –XX:TargetSurvivorRatio=90
–XX:MaxTenuringThreshold=31
–XX:ParallelGCThreads=20：設置 20 個線程進行垃圾回收；
–XX:+UseParNewGC：年輕代使用並行回收器；
–XX:+UseConcMarkSweepGC：年老代使用 CMS 收集器降低停頓；
–XX:+SurvivorRatio：設置 Eden 區和 Survivor 區的比例為 8:1。稍大的 Survivor 空間可以提高在年輕代回收生命周期較短的對象的可能性，如果 Survivor 不夠大，一些短命的對象可能直接進入年老代，這對系統來說是不利的。
–XX:TargetSurvivorRatio=90：設置 Survivor 區的可使用率。這里設置為 90%，則允許 90%的 Survivor 空間被使用。默認值是 50%。故該設置提高了 Survivor 區的使用率。當存放的對象超過這個百分比，則對象會向年老代壓縮。因此，這個選項更有助於將對象留在年輕代。
–XX:MaxTenuringThreshold：設置年輕對象晉升到年老代的年齡。默認值是 15 次，即對象經過 15 次 Minor GC 依然存活，則進入年老代。這里設置為 31，目的是讓對象盡可能地保存在年輕代區域。
除此之外可以性能調優
在CPU負載不足的同時，偶爾會有用戶反映請求的時間過長，意識到必須對程序及JVM進行調優。從以下幾個方面進行：
線程池：解決用戶響應時間長的問題
連接池：鏈接時長和連接數 等
JVM啟動參數：調整各代的內存比例和垃圾回收算法，提高吞吐量
程序算法：改進程序邏輯算法提高性能
一切都是為了這一步，調優，在調優之前，需要記住下面的原則：
1、多數的Java應用不需要在服務器上進行GC優化；
2、多數導致GC問題的Java應用，都不是因為我們參數設置錯誤，而是代碼問題；
3、在應用上線之前，先考慮將機器的JVM參數設置到最優（最適合）；
4、減少創建對象的數量；
5、減少使用全局變量和大對象,動態代理等
6、GC優化是到最后不得已才采用的手段；
7、在實際使用中，分析GC情況優化代碼比優化GC參數要多得多
GC優化的目的有兩個
1、將轉移到老年代的對象數量降低到最小；
2、減少full GC的執行時間；
為了達到上面的目的，一般地，你需要做的事情有：
1、減少使用全局變量和大對象；
2、調整新生代的大小到最合適；
3、設置老年代的大小為最合適；
4、選擇合適的GC收集器；
進行監控和調優
1、監控GC的狀態
2、GC頻率不高，GC耗時不高，那么沒有必要進行GC優化；如果GC時間超過1-3秒，或者頻繁GC，則必須優化