Java優化策略在鐵路互聯網售票系統中的應用研究

楊立鵬，王 拓，劉卓華，李 雯

（1.北京經緯信息技術公司，北京 100081；2.中國鐵道科學研究院，北京 100081；3.中國鐵道科學研究院 電子計算技術研究所，北京 100081；4.中鐵程科技有限責任公司，北京 100081）

Java優化策略在鐵路互聯網售票系統中的應用研究

楊立鵬1,2，王 拓2,3，劉卓華2,3，李 雯4

（1.北京經緯信息技術公司，北京 100081；2.中國鐵道科學研究院，北京 100081；3.中國鐵道科學研究院 電子計算技術研究所，北京 100081；4.中鐵程科技有限責任公司，北京 100081）

為了使鐵路互聯網售票系統穩定性和高效性能夠得到更好的保證，結合分布式內存數據庫的系統特性和鐵路互聯網售票系統的業務特性，對各種Java虛擬機（JVM）內存管理策略和垃圾回收機制進行了分析和研究，以余票查詢業務系統模塊為例對JVM參數調優過程進行了簡要測試和分析，測試結果表明，優化后的系統具有更好的穩定性和高效性。

鐵路互聯網售票系統；分布式內存數據庫；Java虛擬機； Java調優策略

在鐵路互聯網售票系統中，分布式內存數據庫承擔著一些并發請求多、實時性要求高的業務，比如余票查詢、訂單查詢、常用聯系人查詢等。它的構成包括以下2個重要角色：（1）2個Locator作為控制節點，主要負責作業調度、負載均衡。一般部署在2臺服務器上，雙活機制，互為備份，分配少量資源即可。（2）多個DataStore作為服務節點，主要負責數據存儲、邏輯運算。一般部署在多臺服務器上，每臺服務器上的DataStore大小和數量保持一致。物理上數據分散存儲在不同的DataStore上；邏輯上，所有數據仍是統一的整體。

本質上來說，組成分布式內存數據庫的每一個Locator和DataStore都是一個Java虛擬機（JVM，Java Virtual Machine）。JVM專門為Java應用的運行提供環境，用于分配執行任務和執行內存操作。

JVM中頻繁的全量垃圾回收（FGC，Full Garbage Collection）導致的短暫停頓將會造成糟糕的用戶體驗。更嚴重的情況下，如果發生JVM崩潰，導致售票系統某一模塊無法正常提供服務，甚至會引發停售的事故。因此，JVM的穩定性和高效性必須得到最大的保證，JVM的調優顯得尤為重要。

本文將對JVM的各種調優參數進行研究，結合分布式內存數據庫的系統特性和鐵路互聯網售票系統的業務特性，對各種JVM內存管理策略、垃圾回收機制進行分析和研究，最終找出適合特定業務模塊的JVM參數。

1 JVM調優策略

自Java誕生以來，市場上涌現出多款優秀的具有特色的JVM產品，比如HotSpot VM，JRockit，J9等。在生產環境中，我們使用了相對比較穩定的HotSpot VM作為分布式內存數據庫所使用的JVM。

JVM將它所管理的內存空間劃分為若干個不同的區域，這些區域各司其職，維護著對象或者線程的生命周期。如果分配給某個對象的內存地址空間不再被任何對象引用所指向時，那么這塊內存地址空間就成了“垃圾”，占用著寶貴的內存。此時JVM會啟動垃圾回收器，釋放垃圾內存空間，并進行內存整理。

1.1 JVM內存分配策略

Java虛擬機的基本結構如圖1所示。

圖1 Java虛擬機的基本結構示意圖

從線程角度來看，Java運行時數據區域分為全部線程共享數據區域（圖1中綠色部分）和各個線程私有數據區域（圖1中藍色部分）。

（1）程序計數器：Java程序運行時，通過改變這個計數器的值來選取下一條需要執行的字節碼指令。包括程序中的分支、循環、異常處理等基礎功能。

（2）虛擬機棧：執行Java方法時，主要用于存儲棧幀（Stack Frame），棧幀內保存有局部變量表（基本數據類型和對象引用等）、動態鏈接、方法出口等信息。

（3）本地方法棧：與虛擬機棧的功能類似，但本地方法棧是虛擬機執行本地方法時所使用的內存區域。

（4）方法區：可將其稱為Non-Heap，即非堆內存區域。虛擬機加載成功的類信息、常量、靜態變量等數據存儲在這里。

（5）堆：Java堆（Heap）是Java虛擬機管理的內存區域中最大的一塊，用于存放所有對象實例和數組。

對JVM的調優主要集中在Java堆上，它的構成主要包括以下3部分[1]：

（1）年輕代區域：包括Eden空間、FromSurvivor空間、ToSurvivor空間。所有新生成的對象首先都是放在年輕代。年輕代的目標就是盡可能快速地對生命周期短的對象進行垃圾回收。

（2）年老代區域：主要是指Tenured空間。在年輕代中經歷了N次垃圾回收后仍然存活的對象，就會被放到年老代中。因此，可以認為年老代中存放的都是一些生命周期較長的對象。

（3）持久代區域：主要是指Perm空間。用于存放靜態文件，如Java類、方法等。持久代對垃圾回收沒有顯著影響。

1.2 垃圾收集算法

（1）Mark-Sweep標記清除算法：該算法是其他算法的理論基礎。可分為“標記”和“清除”兩個階段，首先從根節點開始，標記上所有可達對象，那么剩余的就是未被引用的垃圾對象，這些是要清除的對象。該算法最大的缺陷是會產生大量的內存空間碎片，導致以后在程序運行過程中需要分配較大對象時，無法找到足夠的連續內存而不得不提前觸發另一次垃圾收集動作[2～3]。

（2）Copying復制算法：該算法的核心思想是將內存控件劃分為大小相等的兩塊，每次只使用其中一塊。在進行垃圾回收時，將存活對象復制到另外一塊中，再把已使用過的內存空間全部清空。雖然這種算法效率很高，也避免了內存空間碎片，但將系統內存折半使用的代價太大了，所以不能單純使用這種算法[2～3]。

（3）Mark-Compact標記壓縮算法：該算法垃圾回收的目標主要是年老代的未被引用對象。它是對Mark-Sweep算法的優化，標記可達對象之后，并不是直接清理未被標記對象，而是將所有存活對象壓縮移動到內存的另一端，之后清理邊界之外的所有內存空間。最終效果與Mark-Sweep相同，但進行了一次內存碎片整理[2～3]。

（4）Generation Collection分代收集算法：該算法根據對象生命周期的不同將內存空間劃分為幾塊不同的區域，使用上述不同的算法。例如，年輕代適合使用復制算法，年老代適合使用標記壓縮算法[2～3]。

1.3 垃圾收集器

垃圾收集器是垃圾收集算法的具體實現[4～5]。

（1）Serial串行收集器：這是最早的垃圾收集器，是單線程的，獨占式的，運行時需要暫停所有線程，直到它運行結束。

（2）ParNew并行收集器：該垃圾收集器適用于年輕代，將串行收集器多線程化。在收集過程中，引用程序會全部暫停，但是在處理能力較強的CPU上，由于使用了多線程，它的停頓時間較短。

（3）CMS（Concurrent-Mark-Sweep）收集器：該收集器是基于Mark-Sweep標記清除算法的使用多線程并發回收的垃圾收集器。CMS收集器的內存回收過程是與用戶線程一起并發執行的，包括4個階段：初始標記(CMS initial mark)、并發標記(CMS concurrent mark)、重新標記(CMS remark)、并發清除(CMS concurrent sweep)。可以通過調整-XX:CM SInitiatingOccupancyFraction參數的值來改變觸發收集動作時年老代空間使用的百分比，這樣就使垃圾回收次數變得可控，應用性能也在一定程度上得到了保證。它的優點是并發收集，停頓較低。但是，在并發收集過程中，會占用一部分CPU資源，導致應用程序變慢，系統吞吐量下降。

（4）G1（Gabbage-First）收集器：該收集器出現在JDK 1.7中，主要就是為了替代1.6時代的CMS。G1收集器也是分代垃圾收集器的一種，但它不要求年輕代和年老代都連續。G1和CMS都可以降低應用停頓時間，但G1建立了可預測時間模型，可以指定最大停頓時間，如果停頓超過這個時間，則G1會嘗試調整年輕代、年老代的比例，調整堆大小等手段進行優化。G1可以避免在整個Java堆中進行全區域的垃圾收集，它在后臺維護一個垃圾收集價值優先列表，保證了G1收集器在有限的時間內可以獲取盡可能高的收集效率。

2 優化過程分析

2.1 JVM監控工具

2.1.1 JDK性能監控工具

在JDK的開發包中，有一些輔助工具可以幫助我們查看JVM進程的運行狀態、Java線程的詳細信息、垃圾回收（GC，Garbage Collection）情況的詳細信息等。

（1）jstat命令。用于查看虛擬機實時運行信息。常用參數如下：

-gc：顯示與GC相關的Heap信息；

-gccapacity：顯示各個代的容量和使用情況；

-gccause：顯示最近一次或正在進行的垃圾收集的原因；

-gcutil：顯示垃圾收集的詳細信息。

（2）jmap命令。這個命令有很多功能，可以導出Heap到文件，即生成Heap內存區域的Dump文件，可以查看Heap內對象實例的統計信息，還可以查看類加載器ClassLoader的詳細信息等。例如，在Linux環境下，生成PID為12345的JVM進程對象統計信息，將結果輸出到文件pid_12345_dump.txt中，可以使用如下命令：

jmap –histo 12345 ＞ pid_12345_dump.txt

（3）jstack命令。用于查看線程堆棧，導出JVM的線程堆棧，經常用來檢查程序的死鎖問題。在實際運行中，往往一次dump的信息無法全面的定位問題，一般需要進行3次線程dump，結合起來進行分析。

2.1.2 可視化性能監控工具VisulVM

VisulVM是一款適用于Java虛擬機且功能十分強大的故障診斷和性能分析可視化工具。VisulVM具有以下優點：（1）它支持擴展插件，用戶可以根據自己Java應用的實際情況進行個性化定制；（2）它同時支持Windows環境下本地啟動的JVM進程，也支持遠程訪問Linux環境下的JVM進程；（3）可進行Thread Dump、內存SnapShot分析、垃圾收集情況分析；（4）界面直觀清晰，通常會有多個視圖分別實時地顯示CPU使用情況、內存使用情況、線程狀態以及其他一些有用信息。

2.2 優化過程

不同業務或不同環境都會對Java應用的運行產生不同影響。以余票查詢業務為例，該業務具有如下幾個主要特點：

（1）全部數據量約有4 000萬條記錄，每次查詢得到的結果集少則幾條，多則200～300條；

（2）業務邏輯十分復雜，涉及多個子模塊，多個表的數據，余票查詢結果中包含車次、席位、預售期等復雜信息；

（3）業務代碼運行頻繁，售票高峰日期時，單日查詢請求數量可達上億次。

由此可以歸納出：業務運行期間會有大量的對象生成、銷毀；對CPU、內存、網絡等資源比較敏感；生產環境的應用必須盡可能減少FGC導致的Stop The World的影響，不能影響用戶體驗，不能影響鐵路售票。

下面將結合服務器硬件、軟件環境和業務應用情況進行調優分析和研究，對各個參數的選取作出說明。

分布式內存數據庫服務器硬件環境如表1所示。

表1 分布式內存數據庫服務器硬件環境

JVM啟動參數如表2所示。

表2 JVM啟動參數列表

在鐵路互聯網售票系統分布式內存數據庫中，根據不同的業務場景，對JVM的啟動參數有定制化的配置。通過對業務場景和系統運行環境的深入分析和充分測試，所選用的參數適用于余票查詢業務和分布式內存數據庫。具體調優思路如下：

（1）-Xmx和-Xms參數：這兩個值設置為相同，以避免每次GC之后JVM重新分配內存。目的是為了讓Heap區域靜態分配，否則Java的堆是動態變化的。經過對余票查詢原始數據量以及業務運行過程中產生對象的數量進行精密測算，這里Heap區域的大小固定為102 400 MB。

（2）-Xmn參數：年輕代大小對系統性能影響比較大，這里我們取整個Heap區域的3/8左右，符合Hotspot VM官方推薦的配置。

（3）-Xss參數：由于余票查詢業務邏輯十分復雜，涉及數據較多，不同車站間的車次數量不同，最多的可達300多趟列車，再考慮到服務器的CPU情況，為保證這種余票查詢請求能夠正常進行，這里將每個線程棧設置為1 024 KB。在相同物理內存下，減小這個值能生成更多的線程。

（4）-XX:PermSize參數：余票查詢業務并沒有相當大量的class需要動態載入或卸載，所以這里設置為128 MB即可。

（5）-XX:+UseParNewGC和-XX:+UseConc-MarkSweepGC參數：使用較為通用的配置。

（6）-XX:CMSInitiatingOccupancyFraction參數：生產環境實際應用中，年老代增長速度并不是很快，而且不允許系統頻繁進行CMS垃圾收集，所以這里將參數值設置較高，為80。

（7）-XX:ParallelGCThreads=4參數：允許有4個線程同時進行垃圾回收。生產環境中，一臺服務器有32個Core，4個JVM，每個JVM分到8個Core，一般可將這個參數設置為8/2=4，如果設置為8個，可能會產生業務線程和GC線程之間的資源競爭。

2.3 優化結果

為了能夠清晰直觀地展現優化效果，采用JDK性能監控工具jstat等命令，將JVM關鍵指標記錄到表格，進行分析。采用對分布式內存數據庫進行壓力測試的方法作為驗證手段，選取具有代表性的垃圾回收操作用時作為觀察指標。

以此為基礎，分別對優化前、優化后的分布式內存數據庫進行壓力測試，每次持續時長1 h，各進行15次，使用jstat命令記錄垃圾回收的頻率（即JVM間隔多少秒進行垃圾回收），取1 h之內的平均值，結果如圖2所示。

圖2 多次壓力測試時垃圾回收用時示意圖

在進行優化之前，進行了15次相同場景的壓力測試，JVM進行垃圾回收的平均時間間隔為1.77 s。而做過優化之后，這一時間間隔提升至7.84 s。系統進行垃圾回收的頻率得到大幅降低，系統能夠更加穩定、更加高效地提供服務。

3 結束語

分布式內存數據庫的主要存儲介質是內存，業務數據和代碼存儲在各個JVM上，同時，為適應鐵路互聯網售票系統的業務場景和高并發訪問需求，我們必須將JVM的調優工作做到精益求精。本文結合生產環境實踐經驗以及其他類似系統的參考信息，對承載余票查詢業務的分布式內存數據庫JVM參數調優過程進行了簡要測試和分析。以此結論為依據的配置，在生產環境取得了穩定且良好的應用效果。

類似的調優思想在其他系統中也得到了良好應用。例如，在用戶行為分析系統中，用戶在使用互聯網售票系統購票過程中，鍵盤錄入等事件均會產生旅客的行為操作數據，對此類數據的分析要求JVM組成的系統能夠承載較大的吞吐量，對實時性要求較低，可以在一定程度上容忍垃圾回收帶來的負面影響。

另外，還有一些調優工作值得進行嘗試，例如，對JDK 1.7中G1垃圾回收器進行充分測試，以論證其在生產系統中使用的可行性。

[1]楊文超.Java虛擬機內存管理與優化策略[J].電子測試，2013（19）：43-44.

[2]嵇智源，潘 巍.面向大數據的內存數據管理研究現狀與展望[J].計算機工程與設計，2014（10）：3499-3506.

[3]李永遠.JAVA虛擬機相關技術研究與實踐[J].信息通信，2015（5）：120-120.

[4]吳志軍，何加銘，曾興斌，等.基于嵌入式Java虛擬機的垃圾收集優化算法[J].計算機工程，2012，38（7）：46-48.

[5]曾天慧，於時才，董榮輝，等.Java垃圾收集機制及性能調節[J].計算機工程與設計，2006，27（17）：3242-3244.

責任編輯 付 思

Java tuning strategy in Railway Internet Ticketing and Reservation System

YANG Lipeng1,2,WANG Tuo2,3,LIU Zhuohua2,3,LI Wen4
( 1.Beijing Jingwei Information Technology Co.,Beijing 100081,China;2.China Academy of Railway Sciences,Beijing 100081,China;3.Institute of Computing Technologies,China Academy of Railway Sciences,Beijing 100081,China;4.China Rails Travel Technology,Co.Ltd., Beijing 100081,China)

In order to make the Railway Internet Ticketing and Reservation System be better guaranteed,combining with the system characteristics of the distributed memory database and the operational characteristics of the Railway Internet Ticketing and Reservation System,this article analyzed and studied on the memory management strategy and garbage collection mechanism of various JVM ( Java virtual machine).Taken remaining ticket query service system model as an example,the JVM parameter tuning process was briefy tested and analyzed.The test result showed that the optimized system had better stability and high effciency.

Railway Internet Ticketing and Reservation System;distributed memory data base;Java virtual machine;Java tuning strategy

U293.22：TP39

A

1005-8451（2016）08-0021-05

2015-12-17

楊立鵬，在讀博士研究生；王 拓，助理研究員。