最大化 AIX 上的 Java 性能，第 3 部分: 更多就是更好
http://www.ibm.com/developerworks/cn/aix/library/es-Javaperf/es-Javaperf3.html
最大化 AIX 上的 Java 性能，第 3 部分: 更多就是更好
這個(gè)由五個(gè)部分組成的系列提供了若干技巧和技術(shù)，這些技巧和技術(shù)通常用于優(yōu)化 Java? 應(yīng)用程序，以便在 AIX? 上實(shí)現(xiàn)最佳的性能。其中還提供了有關(guān)每個(gè)技巧的適用性討論。使用這些技巧，您應(yīng)該能夠快速優(yōu)化 Java 環(huán)境，以適合應(yīng)用程序的需要。
查看本系列更多內(nèi)容?
2008 年 1 月 03 日
- 內(nèi)容
在 IBM Bluemix 云平臺(tái)上開(kāi)發(fā)并部署您的下一個(gè)應(yīng)用。
引言
這是由五部分組成的有關(guān) AIX 上的 Java 性能優(yōu)化的系列中的第三篇文章。強(qiáng)烈建議您在進(jìn)一步繼續(xù)之前閱讀本系列中的第 1 部分（如果您還沒(méi)有這樣做的話(huà)）。
本文集中于涉及各種類(lèi)型的內(nèi)存結(jié)構(gòu)（Java 堆、本機(jī)堆、堆棧）的優(yōu)化，并研究用于優(yōu)化系統(tǒng)以進(jìn)行大小調(diào)整的方法。
您應(yīng)該查看第一部分，以了解適用于大多數(shù)情況的一般技巧。我們還提供了對(duì)于內(nèi)存瓶頸檢測(cè)和研究非常有用的工具的快速參考。下一部分將描述各種類(lèi)型的應(yīng)用程序以及如何優(yōu)化它們。此討論將利用您的應(yīng)用程序知識(shí)來(lái)決定哪些技巧最適合您。第三部分將描述各種技巧。本文在結(jié)束時(shí)將討論一下本系列中的下一篇文章。
回頁(yè)首
內(nèi)存瓶頸
本文討論如何使您的應(yīng)用程序擴(kuò)展到更多數(shù)量的線(xiàn)程或具有更大的堆，或者同時(shí)實(shí)現(xiàn)這兩個(gè)目的。您可能還希望通過(guò)迫使應(yīng)用程序以受約束的方式使用資源，從而使其更加“文明”。在系統(tǒng)由多個(gè)應(yīng)用程序共享的環(huán)境中，這是特別重要的。
當(dāng) AIX Java 應(yīng)用程序嘗試擴(kuò)展時(shí)，存在若干可能會(huì)產(chǎn)生影響的資源瓶頸。Java 堆只是其中之一，并且在大多數(shù)情況下，您只需切換到更大的堆大小即可向上擴(kuò)展。但是還存在另外三個(gè)內(nèi)存方面，它們對(duì)于確定 Java 應(yīng)用程序的內(nèi)存占用空間和可伸縮性具有重要的影響。
除 Java 堆以外的第一個(gè)重要內(nèi)存方面是本機(jī)堆（native heap），文章“Getting more memory in AIX for your Java applications”?描述了如何監(jiān)視本機(jī)堆和調(diào)整其大小。Java 堆由垃圾收集器（Garbage Collector）管理，但是垃圾收集器不會(huì)對(duì)本機(jī)堆執(zhí)行任何操作。因此，如果您看到本機(jī)堆穩(wěn)定地增加，可能是由于不匹配的 JNI 分配（舉例而言）所導(dǎo)致的。
第二個(gè)方面是用?-Xss?指定的本機(jī)堆棧（native stack）。這是針對(duì)每個(gè)線(xiàn)程分配的，并且不基于具體的使用情況，因此如果計(jì)劃運(yùn)行一百個(gè)線(xiàn)程，則要在指定?-Xss2m?前慎重考慮；它將消耗 200 MB 的本機(jī)內(nèi)存，每個(gè)線(xiàn)程消耗 2 MB。在運(yùn)行更多數(shù)量的線(xiàn)程時(shí)，這尤其成為一個(gè)限制因素，建議的解決辦法是使用較小的值而不是使用缺省值。與 JVM 配套的 SDK 指南中提供了有關(guān)此主題的更多信息。
最后，第三個(gè)方面是通過(guò)?-Xoss?控制的 Java 堆棧（Java stack）。使用?-Xoss?指定的值是上限，因此指定一個(gè)較大的值的效果不如使用?-Xss那么顯著。請(qǐng)注意，由于 JIT 編譯，您需要調(diào)整?-Xss?以滿(mǎn)足大多數(shù)需要，并且?-Xoss?通常可以保留不變。例如，需要調(diào)整?-Xoss?的一個(gè)重要場(chǎng)合是在用完了 JNI 引用的時(shí)候。
我們不會(huì)集中于上述任何內(nèi)存方面，因?yàn)槠湔{(diào)整通常是在調(diào)試中出現(xiàn)的，而不是在性能優(yōu)化中出現(xiàn)的。但是如果您陷入了資源不足的情況，現(xiàn)在可以檢查這額外的三個(gè)方面。當(dāng)您將系統(tǒng)利用到極限時(shí)，尤其必須了解這些方面。
談到極限，您應(yīng)該確保?ulimit?設(shè)置不會(huì)在大小調(diào)整期間成為瓶頸。在理想的情況下，我們建議將某些?ulimit?值設(shè)置為無(wú)限大，但是需要將此行為與某個(gè)進(jìn)程消耗完所有本地資源的風(fēng)險(xiǎn)進(jìn)行評(píng)估。對(duì)于性能優(yōu)化工作，您可以首先將?ulimit?值設(shè)置為無(wú)限大，一旦達(dá)到所需的目標(biāo)，您應(yīng)該將這些設(shè)置設(shè)定為有限值。
您可以使用?ulimit -a?命令檢查當(dāng)前的?ulimit?設(shè)置，并且應(yīng)該作為將啟動(dòng) Java 的用戶(hù)帳戶(hù)至少運(yùn)行以下三個(gè)命令：
ulimit -m unlimitedulimit -d unlimitedulimit -f unlimited在某些情況下，您可能不允許執(zhí)行上述操作，因?yàn)檫\(yùn)行 Java 的用戶(hù)帳戶(hù)可能沒(méi)有分配足夠的硬限制：有關(guān)必需的?ulimit?設(shè)置，請(qǐng)參閱位于IBM developer kits for AIX, Java technology edition?的 JVM 配套 SDK 指南。
請(qǐng)注意，與 GC 相關(guān)的問(wèn)題通常會(huì)作為 CPU 資源緊張的問(wèn)題出現(xiàn)，因此如果遇到與 GC 相關(guān)的問(wèn)題，您還應(yīng)該閱讀本系列的第 2 部分。此外，如果 RMI 觸發(fā)了 GC，第 4 部分將對(duì)此進(jìn)行討論。
本部分的其余內(nèi)容將簡(jiǎn)單介紹一些常用的工具和如何檢測(cè)特定于 Java 的問(wèn)題。有關(guān)更多詳細(xì)信息，請(qǐng)參見(jiàn)?AIX 5L Performance Tools Handbook?和?Understanding IBM eServer pSeries Performance and Sizing。
vmstat
vmstat?已在本系列的第 2 部分進(jìn)行了介紹。要從?vmstat?輸出中最需要了解的信息是是否發(fā)生了分頁(yè)，以及分頁(yè)是否是由于堆大小大于可用的物理內(nèi)存而導(dǎo)致的。在大多數(shù)情況下，由于更大的堆而獲得的任何可伸縮性好處，都抵不過(guò)由于堆分頁(yè)而導(dǎo)致的嚴(yán)重性能降低，因此應(yīng)該避免使用較大的堆。
svmon
svmon?是監(jiān)視 Java 進(jìn)程（尤其是本機(jī)堆）時(shí)最有用的工具。文章“When segments collide”（http://www.ibm.com/developerworks/eserver/library/es-segcollide.html）提供了如何使用?svmon -P <pid> -m?來(lái)監(jiān)視 AIX 上的 Java 進(jìn)程本機(jī)堆的示例。但是還存在另一種形式?svmon -P <pid> -m -r，此命令對(duì)于確定本機(jī)堆碎片非常有效。?-r?開(kāi)關(guān)打印正在使用的地址范圍，因此它提供了每個(gè)段的當(dāng)前使用情況的更準(zhǔn)確視圖。例如，請(qǐng)考慮下面經(jīng)過(guò)部分編輯的輸出：
Pid Command Inuse Pin Pgsp Virtual 64-bit Mthrd LPage10556 java 681613 2316 2461 501080 N Y NVsid Esid Type Description LPage Inuse Pin Pgsp Virtual22ac4 9 mmap mapped to sid b1475 - 0 0 - - 21047 8 mmap mapped to sid 30fe5 - 0 0 - - 126a2 a mmap mapped to sid 91072 - 0 0 - - 7908c 7 mmap mapped to sid 6bced - 0 0 - - b2ad6 b mmap mapped to sid b1035 - 0 0 - - b1475 - work - 65536 0 282 65536 30fe5 - work - 65536 0 285 65536 91072 - work - 65536 0 54 65536 6bced - work - 65536 0 261 65536 b1035 - work - 45054 0 0 45054 Addr Range: 0..45055e0f9f 5 work shmat/mmap - 48284 0 3 48284 19100 3 work shmat/mmap - 46997 0 463 47210 c965a 4 work shmat/mmap - 46835 0 281 46953 7910c 6 work shmat/mmap - 37070 0 0 37070 Addr Range: 0..50453e801d d work shared library text - 9172 0 0 9220 Addr Range: 0..30861a0fb7 f work shared library data - 105 0 1 106 Addr Range: 0..252121127 2 work process private - 50 2 1 51 Addr Range: 65300..65535a8535 1 pers code,/dev/q109waslv:81938 - 11 0 - - Addr Range: 0..11如果閱讀過(guò)文章“Getting more memory in AIX for your Java applications”，您應(yīng)該能夠判斷出上述配置是使用 LDR_CNTRL=MAXDATA=0x40000000。“Inuse”列中顯示 4K 頁(yè)的值，因此一個(gè)段（大小為 256 MB）在此列中的最大值將為 65536。正如上述輸出所示，這個(gè)特定的應(yīng)用程序在使用大量的本機(jī)堆；沒(méi)有為段 3-5 打印范圍的原因在于，盡管“Inuse”計(jì)數(shù)不是 65536，但是該段已經(jīng)完全分配了。此外，如果沒(méi)有使用?-r，可以認(rèn)為既然段 6 的“Inuse”值為 37070，則該段只有 56% 的使用率。但是可以判斷出，段 6 正在使用的實(shí)際地址范圍是 0 到 50453，或換句話(huà)說(shuō)該段差不多達(dá)到 77% 的使用率。這會(huì)對(duì)應(yīng)用程序的大小調(diào)整具有重要的影響。
要注意的另一個(gè)有趣部分在于，通過(guò)?svmon?無(wú)法看到 Java 堆碎片。段 7 至 A 看起來(lái)已完全利用（對(duì)應(yīng) SID 的“Inuse”值為 65536），而段 B 正在使用前 45056 個(gè)頁(yè)面。這只是告訴了您該堆的大小約為 1100 MB，但是還存在找到此信息的更容易方法（即查看 Java 的命令行參數(shù)！）。
特定于 Java 的技巧
Fine-tuning Java Garbage Collection Performance?介紹了 Java 堆的優(yōu)化。在 1.4 以前的 Java 版本上，您可能需要調(diào)整某些環(huán)境設(shè)置才能使用超出 1 GB 的堆，“Getting more memory in AIX for your Java applications”對(duì)此進(jìn)行了解釋。
如果您了解 verbosegc 輸出的各項(xiàng)意義，以及如何使用?svmon，對(duì)于 AIX 上的任何 Java 應(yīng)用程序的大多數(shù)性能監(jiān)視工作應(yīng)該足夠了。
存在若干有關(guān) GC 優(yōu)化的文章可以使用，因此基于您希望了解此主題的深度，您可以使用大量的信息。Diagnostics 頁(yè)還指向一個(gè)總結(jié) IBM Java 的 GC 是如何工作的文檔，對(duì)于開(kāi)發(fā)人員來(lái)說(shuō)這應(yīng)該特別有用。下面幾個(gè)部分將堅(jiān)持使用基于特征的優(yōu)化方式，但是如果您希望更進(jìn)一步研究任何特定的技巧，應(yīng)該參考“IBM Garbage Collection and Memory Allocation techniques”一文，您可以從 http://www.ibm.com/developerworks/java/jdk/diagnosis/ 訪(fǎng)問(wèn)它。
回頁(yè)首
基于特征的優(yōu)化技巧
下面我們將看一下典型應(yīng)用程序的不同特征。您應(yīng)該定位到與您的應(yīng)用程序類(lèi)似的行為（無(wú)論是設(shè)計(jì)上的還是觀察到的），并應(yīng)用對(duì)應(yīng)的技巧。除非明確指明，否則術(shù)語(yǔ)“堆”是指 Java 堆。
堆使用情況
對(duì)于大多數(shù)應(yīng)用程序，使用固定與可變堆的決定是很容易做出的。任何具有或多或少的有限堆要求的應(yīng)用程序都可以使用?技巧 MEM001，而任何會(huì)定期猛增堆使用量的應(yīng)用程序使用技巧 MEM002?效果會(huì)更好。但是，如果應(yīng)用程序逐漸地增長(zhǎng)，或者如果您在考慮由于可變堆大小而導(dǎo)致的性能影響，則技巧 MEM001 也許仍然是可行的。位于?IBM developer kits - diagnosis documentation?的診斷指南包括一個(gè)有關(guān)如何調(diào)整 Java 堆大小的不錯(cuò)的內(nèi)容。正如“Fine-tuning Java Garbage Collection Performance”所提到的，要遵循的規(guī)則是：分配應(yīng)用程序需要的堆大小，但是決不多分配。但是在決定使用技巧 MEM001?之前，請(qǐng)參閱有關(guān)“堆回收”的部分。
堆增長(zhǎng)速度
如果應(yīng)用程序堆需要迅速增長(zhǎng)，則技巧 MEM003?將會(huì)非常有用。能從快速內(nèi)存增長(zhǎng)中獲益的應(yīng)用程序類(lèi)型是在工作日的特定時(shí)間具有內(nèi)存需求高峰的應(yīng)用程序。如果優(yōu)化得當(dāng)，堆擴(kuò)展次數(shù)將會(huì)減少，因?yàn)槊看螖U(kuò)展會(huì)將堆增長(zhǎng)更大的量。
另一方面，如果希望控制堆增長(zhǎng)速度，請(qǐng)參見(jiàn)技巧 MEM004。當(dāng)您看到堆擴(kuò)展相當(dāng)大并且希望控制擴(kuò)展增量時(shí)，這是非常有用的。此類(lèi)情況非常罕見(jiàn)，因?yàn)?Java 通常會(huì)基于定義良好的規(guī)則來(lái)擴(kuò)展堆，除非您首先使用技巧 MEM003，否則堆不會(huì)快速增長(zhǎng)。不過(guò)在需要時(shí)使用技巧 MEM004?還是有用的。
如果應(yīng)用程序堆只應(yīng)該增長(zhǎng)而決不會(huì)收縮，可以使用?技巧 MEM005?來(lái)強(qiáng)制實(shí)現(xiàn)此目的。GC 周期不斷監(jiān)視堆使用情況，并在看到分配的堆大于當(dāng)前需求時(shí)收縮堆。畢竟，這就是使用可變大小的堆的本意。但是有時(shí)，您可能注意到在堆收縮后，由于堆需求的增長(zhǎng)而緊跟著進(jìn)行堆擴(kuò)展。在此情況下，您可以要求 JVM 不要收縮堆。
堆回收
如果應(yīng)用程序生成大量的臨時(shí)對(duì)象，如果可以設(shè)置足夠小的堆，則技巧 MEM001?將會(huì)很有幫助。其基本思路在于，如果堆增長(zhǎng)到 200 MB 后觸發(fā)一個(gè) 200 毫秒的 GC 周期，而不是增長(zhǎng)到 1 GB 后觸發(fā)一個(gè) 1500 毫秒的 GC 周期，則使用較小的堆效果會(huì)好得多，因?yàn)閼?yīng)用程序無(wú)論如何都不需要較大的內(nèi)存占用空間。這當(dāng)然是假設(shè)最大的堆大小始終滿(mǎn)足用于長(zhǎng)期分配所需的堆空間量。此技巧與?第 2 部分的技巧 CPU012?相同，但現(xiàn)在是集中于應(yīng)用程序的內(nèi)存占用空間，而不只是集中于應(yīng)用程序的性能。
即使分配相當(dāng)迅速，固定大小的堆通常也工作得很好。但是如果這些臨時(shí)對(duì)象的大小通常相當(dāng)大，則堆會(huì)很快變得零碎，從而導(dǎo)致假性 OOM。不適合使用技巧 MEM001?的另一個(gè)場(chǎng)景是固定 (Pinned) 對(duì)象正在導(dǎo)致碎片的情況。如果必須將對(duì)象固定在堆中，則將它們分配在堆中盡可能低的位置是有幫助的。但是除非非做不可，否則 Java 不會(huì)收集垃圾，因此只要有堆可用，就不會(huì)觸發(fā)任何 GC 周期，并且這會(huì)轉(zhuǎn)化為以導(dǎo)致碎片的方式分配固定對(duì)象。
較新版本的 Java 能夠執(zhí)行更好的碎片管理，并且可以使用新的開(kāi)關(guān)來(lái)調(diào)整固定集群的大小（請(qǐng)參見(jiàn) -Xk 和 –Xp）。但是如果您遇到堆碎片，技巧 MEM002?也許能滿(mǎn)足您的所有需要。在許多情況下，堆擴(kuò)展和收縮能夠比壓縮周期更好地消除堆中的空隙。堆碎片會(huì)嚴(yán)重影響應(yīng)用程序的可伸縮性，技巧 MEM002 是在這些情況下使用的理想調(diào)整。
GC 活動(dòng)
下面是基于 verbosegc 輸出的簡(jiǎn)單指示信息。有關(guān)更多詳細(xì)信息，請(qǐng)參閱“Fine-tuning Java Garbage Collection Performance”。
- 如果您在使用技巧 MEM002，并且在應(yīng)用程序穩(wěn)定時(shí)觀察到太多的 GC，請(qǐng)參見(jiàn)技巧 MEM007。您可能還希望嘗試一下技巧 MEM001，并確定它是否有幫助。
- 如果觀察到堆擴(kuò)展或收縮得太頻繁，可以使用技巧 MEM001?來(lái)同時(shí)消除收縮和擴(kuò)展。技巧 MEM005?將消除任何堆收縮。
- 如果 GC 周期中的標(biāo)記時(shí)間太高，您應(yīng)該嘗試?MEM006。這也可能是由于“標(biāo)記堆棧溢出 (Mark Stack Overflow)”所導(dǎo)致的。
- 如果 GC 周期不是由于“分配故障 (Allocation Failure)”所導(dǎo)致的，可以使用技巧 MEM007。不過(guò)分布式 GC 調(diào)用不會(huì)受到此設(shè)置的影響。
- 如果 verbosegc 中指示了過(guò)多的壓縮，這可能與某個(gè)大小調(diào)整不足的堆有關(guān)。
本機(jī)堆
如果應(yīng)用程序的本機(jī)代碼發(fā)出多個(gè)小請(qǐng)求，則使用技巧 MEM008?也許會(huì)獲得性能提升。但是本機(jī)堆調(diào)整的最重要部分是確保每一次本機(jī)堆分配都與相應(yīng)的回收相匹配。可以使用?svmon?監(jiān)視本機(jī)堆，并且您可能希望設(shè)置 IBM_JAVA_MMAP_JAVA_HEAP=true，以便更清楚地區(qū)分 Java 堆和本機(jī)堆。除了確保應(yīng)用程序不會(huì)在運(yùn)行時(shí)耗盡本機(jī)堆以外，通常沒(méi)有多少針對(duì)本機(jī)堆的性能優(yōu)化余地。
回頁(yè)首
一般技巧集合
下文將把 Java 的命令行參數(shù)（在 class/jar 文件名稱(chēng)之前指定）稱(chēng)為“開(kāi)關(guān)”。例如，命令行?java -mx2g hello?具有單個(gè)開(kāi)關(guān)?-mx2g。
技巧 MEM001：固定大小的堆
通過(guò)同時(shí)為初始 (-Xms) 和最大 (-Xmx) Java 堆大小指定相同的值，從而創(chuàng)建固定大小的 Java 堆。指定的值應(yīng)該足夠高到不會(huì)導(dǎo)致 OOM，同時(shí)要足夠低到不會(huì)顯著增加 GC 周期時(shí)間。
請(qǐng)注意：指定固定大小的堆意味著您將不能使用?-Xminf/-Xmaxf/-Xmine/-Xmaxe?來(lái)微調(diào) GC 特征。固定大小的堆在許多情況下還容易導(dǎo)致碎片。
技巧 MEM002：可變大小的堆
通過(guò)為?-Xms?和?-Xmx?指定不同的值，或者僅指定?-Xmx，從而創(chuàng)建可變大小的 Java 堆。指定的值應(yīng)該足夠高以避免 OOM，但是應(yīng)該進(jìn)行調(diào)整以避免過(guò)多的堆收縮或擴(kuò)展。
請(qǐng)注意：如果優(yōu)化不當(dāng)，使用可變大小的堆會(huì)產(chǎn)生嚴(yán)重的性能影響。
技巧 MEM003：快速的堆增長(zhǎng)
使用高于缺省值 (1 MB) 的?-Xmine?值。這將允許 Java 堆的最小擴(kuò)展變得更迅速。例如，?-Xmine5m?將允許堆一次增長(zhǎng) 5 MB（或更多，最多可達(dá)?-Xmaxe）。
請(qǐng)注意：-Xmine?只是在進(jìn)行堆擴(kuò)展時(shí)發(fā)揮作用的若干因素之一。有關(guān)堆擴(kuò)展的更多信息，請(qǐng)參見(jiàn) Diagnostics Guides。
技巧 MEM004：受控的堆增長(zhǎng)
使用與缺省值 (0) 不同的?-Xmaxe?值。這會(huì)強(qiáng)制將 Java 堆的最大擴(kuò)展保持在指定的限制之內(nèi)。例如，-Xmaxe2m?將強(qiáng)制堆在一個(gè)周期中的增長(zhǎng)不能超過(guò) 2MB。
請(qǐng)注意：?-Xmaxe?只是在進(jìn)行堆擴(kuò)展時(shí)發(fā)揮作用的若干因素之一。有關(guān)堆擴(kuò)展的更多信息，請(qǐng)參見(jiàn)位于?IBM developer kits - diagnosis documentation?的 Diagnostics Guides。
技巧 MEM005：禁用堆收縮
要禁用堆收縮，可以使用?-Xmaxf1，此開(kāi)關(guān)將最大空閑堆百分比設(shè)置為 100%。
請(qǐng)注意：這將強(qiáng)制堆只能增長(zhǎng)，如果堆具有固定大小，則此開(kāi)關(guān)不起作用。
技巧 MEM006：使用并發(fā)標(biāo)記 (Concurrent Mark)
使用開(kāi)關(guān)?-Xgcpolicy:optavgpause?以啟用并發(fā)標(biāo)記。
請(qǐng)注意：對(duì)于 CPU 密集型應(yīng)用程序，此設(shè)置可能會(huì)影響性能。
技巧 MEM007：禁用顯式的 GC 調(diào)用
使用開(kāi)關(guān)?-Xdisableexplicitgc?禁用任何?System.gc()?調(diào)用以避免觸發(fā) GC。
請(qǐng)注意：確保您的應(yīng)用程序功能不會(huì)受到此開(kāi)關(guān)的影響。
技巧 MEM008：優(yōu)化本機(jī)堆分配
設(shè)置環(huán)境變量：
export MALLOCTYPE=buckets以切換到基于 Bucket 的本機(jī)堆模型。
請(qǐng)注意：Java 堆分配不受此開(kāi)關(guān)的影響。而且，如果使用不當(dāng)，此開(kāi)關(guān)會(huì)影響應(yīng)用程序的性能。
回頁(yè)首
總結(jié)
本文向您介紹了如何使用 AIX 工具進(jìn)行 Java 性能監(jiān)視，并提供了可用來(lái)優(yōu)化應(yīng)用程序的內(nèi)存使用的常用調(diào)整列表。本系列中的下一篇文章將討論“AIX 上的 Java 應(yīng)用程序的網(wǎng)絡(luò)和磁盤(pán) I/O 調(diào)整”。
參考資料
學(xué)習(xí)
- 本系列文章的其他部分：
- 第 1 部分
- 第 2 部分
- 第 4 部分
- 第 5 部分
轉(zhuǎn)載于:https://www.cnblogs.com/anruy/p/4919403.html
總結(jié)
以上是生活随笔為你收集整理的最大化 AIX 上的 Java 性能，第 3 部分: 更多就是更好的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： Java虚拟机10：类加载器
- 下一篇： Java 螺纹第三版 第三章数据同步 读