一区二区三区三上|欧美在线视频五区|国产午夜无码在线观看视频|亚洲国产裸体网站|无码成年人影视|亚洲AV亚洲AV|成人开心激情五月|欧美性爱内射视频|超碰人人干人人上|一区二区无码三区亚洲人区久久精品

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評(píng)論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫(xiě)文章/發(fā)帖/加入社區(qū)
會(huì)員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

深度解析JVM調(diào)優(yōu)實(shí)踐應(yīng)用

馬哥Linux運(yùn)維 ? 來(lái)源:cnblogs ? 2024-04-01 10:24 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

Tomcat自身的調(diào)優(yōu)是針對(duì)conf/server.xml中的幾個(gè)參數(shù)的調(diào)優(yōu)設(shè)置。首先是對(duì)這幾個(gè)參數(shù)的含義要有深刻而清楚的理解。以tomcat8.5為例,講解參數(shù)。

同時(shí)也得認(rèn)識(shí)到一點(diǎn),tomcat調(diào)優(yōu)也受制于linux內(nèi)核。linux內(nèi)核對(duì)tcp連接也有幾個(gè)參數(shù)可以調(diào)優(yōu)。

因此我們可以將tomcat調(diào)優(yōu)分為linux內(nèi)核優(yōu)化、java虛擬機(jī)調(diào)優(yōu)和tomcat自身的優(yōu)化。

一、Tomcat自身優(yōu)化

1. maxThreads:tomcat創(chuàng)建的最大線程數(shù),也就是同時(shí)處理的請(qǐng)求最大并發(fā)數(shù)。默認(rèn)值是200

官網(wǎng):The maximum number of request processing threads to be created by this Connector, which therefore determines the maximum number of simultaneous requests that can be handled. If not specified, this attribute is set to 200. If an executor is associated with this connector, this attribute is ignored as the connector will execute tasks using the executor rather than an internal thread pool. Note that if an executor is configured any value set for this attribute will be recorded correctly but it will be reported (e.g. via JMX) as -1to make clear that it is not used.

maxThreads如何配置(轉(zhuǎn))

一般的服務(wù)器操作都包括量方面:1計(jì)算(主要消耗cpu),2等待(io、數(shù)據(jù)庫(kù)等)

第一種極端情況,如果我們的操作是純粹的計(jì)算,那么系統(tǒng)響應(yīng)時(shí)間的主要限制就是cpu的運(yùn)算能力,此時(shí)maxThreads應(yīng)該盡量設(shè)的小,降低同一時(shí)間內(nèi)爭(zhēng)搶cpu的線程個(gè)數(shù),可以提高計(jì)算效率,提高系統(tǒng)的整體處理能力。

第二種極端情況,如果我們的操作純粹是IO或者數(shù)據(jù)庫(kù),那么響應(yīng)時(shí)間的主要限制就變?yōu)榈却獠抠Y源,此時(shí)maxThreads應(yīng)該盡量設(shè)的大,這樣才能提高同時(shí)處理請(qǐng)求的個(gè)數(shù),從而提高系統(tǒng)整體的處理能力。此情況下因?yàn)閠omcat同時(shí)處理的請(qǐng)求量會(huì)比較大,所以需要關(guān)注一下tomcat的虛擬機(jī)內(nèi)存設(shè)置和linux的open file限制。

我在測(cè)試時(shí)遇到一個(gè)問(wèn)題,maxThreads我設(shè)置的比較大比如3000,當(dāng)服務(wù)的線程數(shù)大到一定程度時(shí),一般是2000出頭,單次請(qǐng)求的響應(yīng)時(shí)間就會(huì)急劇的增加,

百思不得其解這是為什么,四處尋求答案無(wú)果,最后我總結(jié)的原因可能是cpu在線程切換時(shí)消耗的時(shí)間隨著線程數(shù)量的增加越來(lái)越大,

cpu把大多數(shù)時(shí)間都用來(lái)在這2000多個(gè)線程直接切換上了,當(dāng)然cpu就沒(méi)有時(shí)間來(lái)處理我們的程序了。

以前一直簡(jiǎn)單的認(rèn)為多線程=高效率。。其實(shí)多線程本身并不能提高cpu效率,線程過(guò)多反而會(huì)降低cpu效率。

當(dāng)cpu核心數(shù)<線程數(shù)時(shí),cpu就需要在多個(gè)線程直接來(lái)回切換,以保證每個(gè)線程都會(huì)獲得cpu時(shí)間,即通常我們說(shuō)的并發(fā)執(zhí)行。

所以maxThreads的配置絕對(duì)不是越大越好。

現(xiàn)實(shí)應(yīng)用中,我們的操作都會(huì)包含以上兩種類(lèi)型(計(jì)算、等待),所以maxThreads的配置并沒(méi)有一個(gè)最優(yōu)值,一定要根據(jù)具體情況來(lái)配置。

最好的做法是:在不斷測(cè)試的基礎(chǔ)上,不斷調(diào)整、優(yōu)化,才能得到最合理的配置。

2. acceptCount:當(dāng)tomcat的線程數(shù)達(dá)到了最大時(shí),接收排隊(duì)的最大請(qǐng)求個(gè)數(shù)。默認(rèn)值為100

官網(wǎng):the maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 100.

maxThreads與acceptCount這兩個(gè)值是如何起作用的呢?

情況1:接受一個(gè)請(qǐng)求,此時(shí)tomcat起動(dòng)的線程數(shù)沒(méi)有到達(dá)maxThreads,tomcat會(huì)起動(dòng)一個(gè)線程來(lái)處理此請(qǐng)求。

情況2:接受一個(gè)請(qǐng)求,此時(shí)tomcat起動(dòng)的線程數(shù)已經(jīng)到達(dá)maxThreads,tomcat會(huì)把此請(qǐng)求放入等待隊(duì)列,等待空閑線程。

情況3:接受一個(gè)請(qǐng)求,此時(shí)tomcat起動(dòng)的線程數(shù)已經(jīng)到達(dá)maxThreads,等待隊(duì)列中的請(qǐng)求個(gè)數(shù)也達(dá)到了acceptCount,此時(shí)tomcat會(huì)直接拒絕此次請(qǐng)求,返回connection refused。

對(duì)于第3種情況,在看過(guò)一篇分析connection timeout問(wèn)題產(chǎn)生的原因后,等待隊(duì)列的請(qǐng)求個(gè)數(shù)這個(gè)值可能是由acceptCount參數(shù)決定,也有可能由linux內(nèi)核參數(shù)net.core.somaxconn決定。

關(guān)聯(lián):我在網(wǎng)上看來(lái)一篇文章寫(xiě)分析linux上TCP connection timeout的原因,這篇文章中提到一個(gè)內(nèi)核參數(shù) net.core.somaxconn。

我就想tomcat的acceptCount與net.core.somaxconn到底是什么關(guān)系呢。

我做了一個(gè)實(shí)驗(yàn),

1. 我將tomcat的acceptCount設(shè)置為3000 ,net.core.somaxconn設(shè)置為8192

那么我用ss -lt 指令查看在tomcat起的端口上的send_q值是3000 可見(jiàn)這是acceptCount的值。

2.我將tomcat的acceptCount設(shè)置為10000,net.core.somaxconn設(shè)置為8192

同樣用ss -lt指令查看在tomcat起的端口上的send_q值是8192,可見(jiàn)這是somaxconn的值。

所以,我總結(jié)的是,acceptCount設(shè)置的值要一般小于net.core.somaxconn這個(gè)參數(shù),這樣acceptCount的值才會(huì)起作用。net.core.somaxconn 這個(gè)參數(shù)默認(rèn)值是128 ,所以需要改這個(gè)參數(shù)值。后面再介紹改這個(gè)值的方法。

acceptCount如何配置?(轉(zhuǎn))

我一般是設(shè)置的跟maxThreads一樣大,這個(gè)值應(yīng)該是主要根據(jù)應(yīng)用的訪問(wèn)峰值與平均值來(lái)權(quán)衡配置的。

如果設(shè)的較小,可以保證接受的請(qǐng)求較快相應(yīng),但是超出的請(qǐng)求可能就直接被拒絕

如果設(shè)的較大,可能就會(huì)出現(xiàn)大量的請(qǐng)求超時(shí)的情況,因?yàn)槲覀兿到y(tǒng)的處理能力是一定的。

3. maxConnections

官網(wǎng):

The maximum number of connections that the server will accept and process at any given time. When this number has been reached, the server will accept, but not process, one further connection. This additional connection be blocked until the number of connections being processed falls belowmaxConnectionsat which point the server will start accepting and processing new connections again. Note that once the limit has been reached, the operating system may still accept connections based on theacceptCountsetting. The default value varies by connector type. For NIO and NIO2 the default is10000. For APR/native, the default is8192.

Note that for APR/native on Windows, the configured value will be reduced to the highest multiple of 1024 that is less than or equal to maxConnections. This is done for performance reasons.
If set to a value of -1, the maxConnections feature is disabled and connections are not counted.

Tomcat允許的同時(shí)存在的最大連接數(shù)

acceptCount、maxConnections是tcp層相關(guān)的參數(shù)。

4.connectionTimeOut:connectionTimeOut=10000是說(shuō)建立一個(gè)socket連接后,如果一直沒(méi)有收到客戶(hù)端的FIN,也沒(méi)有數(shù)據(jù)過(guò)來(lái),那么此連接也必須等到10s后,才能被超時(shí)釋放,我理解是tomcat就直接釋放這個(gè)連接。以毫秒為單位,server.xml默認(rèn)設(shè)置是20秒。

官網(wǎng):The number of milliseconds this Connectorwill wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 60000 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 20000 (i.e. 20 seconds). UnlessdisableUploadTimeoutis set tofalse, this timeout will also be used when reading the request body (if any).

修改方法:
  vi server.xml 打開(kāi)server.xml文件
將 
 
修改為:
  
修改為


 

下面的圖為T(mén)CP三次握手與accept交互

e66266a2-ef69-11ee-a297-92fbcf53809c.png

SYN隊(duì)列稱(chēng)為半連接隊(duì)列,由內(nèi)核參數(shù) net.ipv4.tcp_max_syn_backlog 設(shè)置.

Accept隊(duì)列稱(chēng)為完全連接隊(duì)列,三次握手已經(jīng)完成,但還未被應(yīng)用層接收(accept),但也處于ESTABLISHED狀態(tài)。隊(duì)列長(zhǎng)度由listen的backlog參數(shù)和內(nèi)核的 net.core.somaxconn 參數(shù)共同決定。由listen()函數(shù)的第二個(gè)參數(shù) backlog 指定,內(nèi)核硬限制由 net.core.somaxconn 限制,即隊(duì)列長(zhǎng)度實(shí)際的值由min(backlog,somaxconn) 來(lái)決定

客戶(hù)端使用connect向服務(wù)器發(fā)送TCP連接,三次握手就發(fā)生了。當(dāng)1.1步驟 客戶(hù)端首先發(fā)送SYN到達(dá)服務(wù)端后,內(nèi)核會(huì)把連接信息放到SYN隊(duì)列中,同時(shí)回一個(gè)SYN+ACK包給客戶(hù)端。一段時(shí)間后,客戶(hù)端再次發(fā)來(lái)ACK包后,內(nèi)核會(huì)把連接從SYN隊(duì)列中取出,再把這個(gè)連接放到ACCEPT隊(duì)列中。應(yīng)用服務(wù)器調(diào)用accept時(shí),其實(shí)就是直接從ACCEPT隊(duì)列中取出已經(jīng)建立成功的連接套接字。

還有一張圖是TCP握手建立連接的流程和隊(duì)列

e6730462-ef69-11ee-a297-92fbcf53809c.png

Tomcat原理概要

Tomcat大致分為兩個(gè)部分,Connector組件及Container組件。Connector組件負(fù)責(zé)控制入口連接,并關(guān)聯(lián)著一個(gè)Executor。Container負(fù)責(zé)Servlet容器的實(shí)現(xiàn),Executor負(fù)責(zé)具體的業(yè)務(wù)邏輯,如Servlet的執(zhí)行。一個(gè)請(qǐng)求到達(dá)服務(wù)器后,經(jīng)過(guò)以下關(guān)鍵幾步,參見(jiàn)下圖:

e68400dc-ef69-11ee-a297-92fbcf53809c.png

OS與客戶(hù)端握手并建立連接,并將建立的連接放入完成隊(duì)列,不妨叫Acceptor Queque。這個(gè)隊(duì)列的長(zhǎng)度就是Connector的acceptCount值。

Tomcat中的acceptor線程,不斷從Acceptor Queque中獲取連接。

Acceptor Queque隊(duì)列中沒(méi)有連接,Acceptor線程繼續(xù)監(jiān)視

Acceptor Queque隊(duì)列中有新連接,Acceptor線程將檢查當(dāng)前的連接數(shù)是否超過(guò)了maxConnections

如果超過(guò)maxConnections,則阻塞。直到連接數(shù)小于maxConnections,acceptor線程將請(qǐng)求交由Executor負(fù)責(zé)執(zhí)行。

Executor將分配worker線程來(lái)處理請(qǐng)求數(shù)據(jù)的讀取,處理(servlet的執(zhí)行)以及響應(yīng)。

acceptCount

acceptCount 實(shí)際上是Bind Socket時(shí)候傳遞的backlog值,在linux平臺(tái)下含義是已經(jīng)建立連接還沒(méi)有被應(yīng)用獲取的連接隊(duì)列最大長(zhǎng)度。此時(shí),如果請(qǐng)求個(gè)數(shù)達(dá)到了acceptCount,新進(jìn)的請(qǐng)求將拋出refuse connection.

二、Linux內(nèi)核參數(shù)優(yōu)化

1. linux系統(tǒng)對(duì)當(dāng)前用戶(hù)的單一進(jìn)程同時(shí)可打開(kāi)的文件數(shù)量的限制

查看系統(tǒng)允許當(dāng)前用戶(hù)進(jìn)程打開(kāi)的文件數(shù)量的限制:ulimit -u 默認(rèn)值為1024 。即是Linux操作系統(tǒng)對(duì)一個(gè)進(jìn)程打開(kāi)的文件句柄數(shù)量的限制

對(duì)于想支持更高數(shù)量的TCP并發(fā)連接的通訊處理程序,就必須修改Linux對(duì)當(dāng)前用戶(hù)的進(jìn)程同時(shí)打開(kāi)的文件數(shù)量的軟限制(soft limit)和硬限制(hardlimit)。其中軟限制是指Linux在當(dāng)前系統(tǒng)能夠承受的范圍內(nèi)進(jìn)一步限制用戶(hù)同時(shí)打開(kāi)的文件數(shù);硬限制則是根據(jù)系統(tǒng)硬件資源狀況(主要是系統(tǒng)內(nèi)存)計(jì)算出來(lái)的系統(tǒng)最多可同時(shí)打開(kāi)的文件數(shù)量。通常軟限制小于或等于硬限制。

修改方法:

sudo vi /etc/security/limits.conf

增加如下:

prouser soft nofile 65536
prouser hard nofile 65536

prouser soft nproc 65536

prouser hard nproc 65536

修改完后保存此文件。

nproc是操作系統(tǒng)級(jí)別對(duì)每個(gè)用戶(hù)創(chuàng)建的進(jìn)程數(shù)的限制

2.Linux網(wǎng)絡(luò)內(nèi)核對(duì)TCP連接的有關(guān)限制

修改方法:

sudo vi /etc/sysctl.conf

增加如下:

net.ipv4.tcp_tw_reuse = 1 
net.ipv4.tcp_tw_recycle = 1 
net.ipv4.tcp_fin_timeout = 30 
net.ipv4.ip_local_port_range = 10000 65000 
net.ipv4.tcp_max_syn_backlog = 8192 
net.ipv4.tcp_max_tw_buckets = 10000
net.core.somaxconn=8192      accept隊(duì)列的長(zhǎng)度跟這個(gè)參數(shù)有關(guān)
 
sudo /sbin/sysctl -p
實(shí)時(shí)生效

三、JVM調(diào)優(yōu)

JAVA_OPTS="$JAVA_OPTS -server -Xmn2000m -Xms4000m -Xmx4000m -XX:PermSize=128m -XX:+UseConcMarkSweepGC -XX:MaxPermSize=512m -Djuli-logback.configurationFile=file:$CATALINA_HOME/conf/logback.xml"

默認(rèn)值:

修改為:

參數(shù)解釋?zhuān)?/span>

maxThreads:最大并發(fā)數(shù),默認(rèn)設(shè)置 200,一般建議在 500 ~ 800,根據(jù)硬件設(shè)施和業(yè)務(wù)來(lái)判斷
minSpareThreads:Tomcat 初始化時(shí)創(chuàng)建的線程數(shù),默認(rèn)設(shè)置 25
maxIdleTime:如果當(dāng)前線程大于初始化線程,那空閑線程存活的時(shí)間,單位毫秒,默認(rèn)60000=60秒=1分鐘。
prestartminSpareThreads:在 Tomcat 初始化的時(shí)候就初始化 minSpareThreads 的參數(shù)值,如果不等于 true,minSpareThreads 的值就沒(méi)啥效果了
maxQueueSize:最大的等待隊(duì)列數(shù),超過(guò)則拒絕請(qǐng)求

審核編輯:黃飛

聲明:本文內(nèi)容及配圖由入駐作者撰寫(xiě)或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場(chǎng)。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問(wèn)題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • cpu
    cpu
    +關(guān)注

    關(guān)注

    68

    文章

    11083

    瀏覽量

    217183
  • TCP
    TCP
    +關(guān)注

    關(guān)注

    8

    文章

    1402

    瀏覽量

    81106
  • 數(shù)據(jù)庫(kù)
    +關(guān)注

    關(guān)注

    7

    文章

    3929

    瀏覽量

    66297
  • JVM
    JVM
    +關(guān)注

    關(guān)注

    0

    文章

    160

    瀏覽量

    12632
  • 線程
    +關(guān)注

    關(guān)注

    0

    文章

    508

    瀏覽量

    20243

原文標(biāo)題:三、JVM調(diào)優(yōu)

文章出處:【微信號(hào):magedu-Linux,微信公眾號(hào):馬哥Linux運(yùn)維】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評(píng)論

    相關(guān)推薦
    熱點(diǎn)推薦

    jvm的類(lèi)加載器的整體結(jié)構(gòu)及過(guò)程解析

    前言 我們很多小伙伴平時(shí)都是做JAVA開(kāi)發(fā)的,那么作為一名合格的工程師,你是否有仔細(xì)的思考過(guò)JVM的運(yùn)行原理呢。 如果懂得了JVM的運(yùn)行原理和內(nèi)存模型,像是一些JVM調(diào)
    的頭像 發(fā)表于 09-27 15:49 ?3635次閱讀
    <b class='flag-5'>jvm</b>的類(lèi)加載器的整體結(jié)構(gòu)及過(guò)程<b class='flag-5'>解析</b>

    java開(kāi)發(fā)人員不了解jvm調(diào)優(yōu)對(duì)工作有影響嗎

    作為一名java開(kāi)發(fā)人員,不了解jvm調(diào)優(yōu)對(duì)工作有什么影響?
    發(fā)表于 04-10 11:57

    JVM性能指標(biāo)分析

    JVM性能調(diào)優(yōu)實(shí)踐——JVM
    發(fā)表于 10-17 15:00

    解析深度學(xué)習(xí):卷積神經(jīng)網(wǎng)絡(luò)原理與視覺(jué)實(shí)踐

    解析深度學(xué)習(xí):卷積神經(jīng)網(wǎng)絡(luò)原理與視覺(jué)實(shí)踐
    發(fā)表于 06-14 22:21

    基于全HDD aarch64服務(wù)器的Ceph性能調(diào)優(yōu)實(shí)踐總結(jié)

    Write)做一個(gè)具體的調(diào)優(yōu)實(shí)踐。6 "4k Seq Write"用例調(diào)優(yōu)首先,我們看一個(gè)Ceph時(shí)延占比的測(cè)試,如下圖:從圖中可以看出,
    發(fā)表于 07-05 14:26

    如何對(duì)電機(jī)進(jìn)行調(diào)優(yōu)調(diào)優(yōu)的好處是什么?

    如何自動(dòng)對(duì)電機(jī)進(jìn)行調(diào)優(yōu)
    的頭像 發(fā)表于 08-22 00:03 ?3468次閱讀

    關(guān)于JVM調(diào)優(yōu)知識(shí)

    最近很多小伙伴跟我說(shuō),自己學(xué)了不少JVM調(diào)優(yōu)知識(shí),但是在實(shí)際工作中卻不知道何時(shí)對(duì)JVM進(jìn)行調(diào)優(yōu)
    的頭像 發(fā)表于 09-14 14:54 ?1065次閱讀

    Alluxio線程池結(jié)構(gòu)與吞吐量調(diào)優(yōu)

    本文介紹了 Alluxio Master 的線程池結(jié)構(gòu)與每個(gè)線程的功能。在調(diào)優(yōu)過(guò)程中,利用分析結(jié)果調(diào)整審計(jì)日志的 blocking queue,調(diào)整 UFS-SYNC-PREFETCH 線程數(shù),調(diào)
    發(fā)表于 11-11 11:36 ?784次閱讀

    javajvm調(diào)優(yōu)有幾種方法

    JVM調(diào)優(yōu)是Java應(yīng)用程序性能優(yōu)化過(guò)程中的重要步驟,它通過(guò)針對(duì)JVM進(jìn)行優(yōu)化來(lái)提高應(yīng)用程序的性能和可靠性。JVM
    的頭像 發(fā)表于 12-05 11:11 ?2431次閱讀

    什么場(chǎng)景需要jvm調(diào)優(yōu)

    JVM調(diào)優(yōu)是指對(duì)Java虛擬機(jī)進(jìn)行性能優(yōu)化和資源管理,以提高應(yīng)用程序的運(yùn)行效率和吞吐量。JVM調(diào)優(yōu)
    的頭像 發(fā)表于 12-05 11:14 ?1778次閱讀

    jvm調(diào)優(yōu)參數(shù)

    JVM(Java虛擬機(jī))是Java程序的運(yùn)行環(huán)境,它負(fù)責(zé)解釋Java字節(jié)碼并執(zhí)行相應(yīng)的指令。為了提高應(yīng)用程序的性能和穩(wěn)定性,我們可以調(diào)優(yōu)JVM的參數(shù)。
    的頭像 發(fā)表于 12-05 11:29 ?982次閱讀

    jvm參數(shù)的設(shè)置和jvm調(diào)優(yōu)

    JVM(Java虛擬機(jī))參數(shù)的設(shè)置和調(diào)優(yōu)對(duì)于提高Java應(yīng)用程序的性能和穩(wěn)定性非常重要。在本文中,我們將詳細(xì)介紹JVM參數(shù)的設(shè)置和調(diào)
    的頭像 發(fā)表于 12-05 11:36 ?2295次閱讀

    jvm調(diào)優(yōu)主要是調(diào)哪里

    JVM調(diào)優(yōu)主要涉及內(nèi)存管理、垃圾回收、線程管理與鎖優(yōu)化等方面。下面將詳細(xì)介紹每個(gè)方面的調(diào)優(yōu)技術(shù)和策略以及如何進(jìn)行優(yōu)化。 內(nèi)存管理
    的頭像 發(fā)表于 12-05 11:37 ?1848次閱讀

    jvm調(diào)優(yōu)常用命令

    JVM調(diào)優(yōu)是提升Java應(yīng)用性能的一個(gè)重要方面,通過(guò)合理設(shè)置JVM參數(shù)可以達(dá)到優(yōu)化應(yīng)用性能、提高系統(tǒng)穩(wěn)定性的目的。本文將為你詳細(xì)介紹JVM
    的頭像 發(fā)表于 12-05 11:43 ?1003次閱讀

    jvm調(diào)優(yōu)工具有哪些

    JVM調(diào)優(yōu)是提高Java應(yīng)用程序性能的重要手段,而JVM調(diào)優(yōu)工具則是輔助開(kāi)發(fā)人員進(jìn)行
    的頭像 發(fā)表于 12-05 11:44 ?1486次閱讀