JVM日志和参数的理解

最新推荐文章于 2024-11-12 15:42:01 发布
最新推荐文章于 2024-11-12 15:42:01 发布
阅读量297 收藏
点赞数
文章标签： 大数据 数据库 java
原文链接：https://my.oschina.net/OQKuDOtsbYT2/blog/416895
版权

jvm日志和参数

 一:理解GC日志格式,读GC日志的方法

1:开启日志

-verbose:gc 

-XX:+PrintGCDetails 

-XX:+PrintGCDateStamps

-Xloggc:/path/gc.log

-XX:+UseGCLogFileRotation  启用GC日志文件的自动转储 (Since Java)

-XX:NumberOfGClogFiles=1  GC日志文件的循环数目 (Since Java)

-XX:GCLogFileSize=1M  控制GC日志文件的大小 (Since Java)

-XX:+PrintGC包含-verbose:gc

-XX:+PrintGCDetails //包含-XX:+PrintGC

只要设置-XX:+PrintGCDetails 就会自动带上-verbose:gc和-XX:+PrintGC

-XX:+PrintGCDateStamps/-XX:+PrintGCTimeStamps 输出gc的触发时间

 2:新生代(Young GC)gc日志分析 

2014-02-28T11:59:00.638+0800: 766.537:[GC2014-02-28T11:59:00.638+0800: 766.537:  
[ParNew: 1770882K->212916K(1835008K), 0.0834220 secs]  
5240418K->3814487K(24903680K), 0.0837310 secs] [Times: user=1.12 sys=0.02, real=0.08 secs]

  2014-02-28T11:59:00 ...（时间戳）:[GC（Young GC）（时间戳）:[ParNew（使用ParNew作为年轻代的垃圾回收期）：

1770882K（年轻代垃圾回收前的大小）->212916K（年轻代垃圾回收以后的大小）(1835008K)（年轻代的capacity）, 0.0834220 secs（回收时间）]
5240418K（整个heap垃圾回收前的大小）->3814487K（整个heap垃圾回收后的大小）(24903680K)（heap的capacity）, 0.0837310secs（回收时间）]
[Times: user=1.12（Young GC用户耗时） sys=0.02（Young GC系统耗时）, real=0.08 secs（Young GC实际耗时）]

   其中 Young GC回收了1770882-212916=1557966K内存，Heap通过这次回收总共减少了 5240418-3814487=1425931 K的内存。1557966-1425931=132035K说明这次Young GC有约128M的内存被移动到了Old Gen，
 提示:进代量(Young->Old)需要重点观察，预防promotion failed.

 3:老年代(CMS old gc)分析 

2014-02-28T23:58:42.314+0800: 25789.661: [GC [1 CMS-initial-mark: 17303356K(23068672K)] 18642315K(24903680K), 1.0400410 secs] [Times: user=1.04 sys=0.00, real=1.04 secs] 2014-02-28T23:58:43.354+0800: 25790.701: [CMS-concurrent-mark-start]  
2014-02-28T23:58:43.717+0800: 25791.064: [CMS-concurrent-mark: 0.315/0.363 secs] [Times: user=1.64 sys=0.02, real=0.37 secs]  
2014-02-28T23:58:43.717+0800: 25791.064: [CMS-concurrent-preclean-start]  
2014-02-28T23:58:43.907+0800: 25791.254: [CMS-concurrent-preclean: 0.181/0.190 secs] [Times: user=0.20 sys=0.01, real=0.19 secs]  
2014-02-28T23:58:43.907+0800: 25791.254: [CMS-concurrent-abortable-preclean-start]  
 CMS: abort preclean due to time 2014-02-28T23:58:49.082+0800: 25796.429: [CMS-concurrent-abortable-preclean: 5.165/5.174 secs] [Times: user=5.40 sys=0.04, real=5.17 secs]  
2014-02-28T23:58:49.083+0800: 25796.430: [GC[YG occupancy: 1365142 K (1835008 K)]2014-02-28T23:58:49.083+0800: 25796.430: [Rescan (parallel) , 0.9690640 secs]2014-02-28T23:58:50.052+0800: 25797.399: [weak refs processing, 0.0006190 secs]2014-02-28T23:58:50.053+0800: 25797.400: [scrub string table, 0.0006290 secs] [1 CMS-remark: 17355150K(23068672K)] 18720292K(24903680K), 0.9706650 secs] [Times: user=16.49 sys=0.06, real=0.97 secs]  
2014-02-28T23:58:50.054+0800: 25797.401: [CMS-concurrent-sweep-start]  
2014-02-28T23:58:51.940+0800: 25799.287: [CMS-concurrent-sweep: 1.875/1.887 secs] [Times: user=2.03 sys=0.03, real=1.89 secs]  
2014-02-28T23:58:51.941+0800: 25799.288: [CMS-concurrent-reset-start]  
2014-02-28T23:58:52.067+0800: 25799.414: [CMS-concurrent-reset: 0.127/0.127 secs] [Times: user=0.13 sys=0.00, real=0.13 secs]  
2014-03-01T00:00:36.293+0800: 25903.640: [GC2014-03-01T00:00:36.293+0800: 25903.640: [ParNew: 1805234K->226801K(1835008K), 0.1020510 secs] 10902912K->9434796K(24903680K), 0.1023150 secs] [Times: user=1.35 sys=0.02, real=0.10 secs]  
2014-03-01T00:07:13.559+0800: 26300.906: [GC2014-03-01T00:07:13.559+0800: 26300.906: [ParNew: 1799665K->248991K(1835008K), 0.0876870 secs] 14086673K->12612462K(24903680K), 0.0879620 secs] [Times: user=1.24 sys=0.01, real=0.09 secs]

 CMS的gc日志分为一下几个步骤，重点关注initial-mark和remark这两个阶段，因为这两个阶段会stop进程。

初始标记（init mark）：收集根引用，这是一个stop-the-world阶段。

并发标记（concurrent mark）：这个阶段可以和用户应用并发进行。遍历老年代的对象图，标记出活着的对象。

并发预清理（concurrent preclean）：这同样是一个并发的阶段。主要的用途也是用来标记，用来标记那些在前面标记之后，发生变化的引用。主要是为了缩短remark阶段的stop-the-world的时间。

重新标记（remark）：这是一个stop-the-world的操作。暂停各个应用，统计那些在发生变化的标记。

并发清理（concurrent sweep）：并发扫描整个老年代，回收一些在对象图中不可达对象所占用的空间。

并发重置（concurrent reset）：重置某些数据结果，以备下一个回收周期

提示:红色为全部暂停阶段重点关注. 

[GC [1 CMS-initial-mark: 17303356K(23068672K)] 18642315K(24903680K), 1.0400410 secs] [Times: user=1.04 sys=0.00, real=1.04 secs]

 其中数字依表示标记前后old区的所有对象占内存大小和old的capacity，整个JavaHeap（不包括perm）所有对象占内存总的大小和JavaHeap的capacity。 

[GC[YG occupancy: 1365142 K (1835008 K)]2014-02-28T23:58:49.083+0800: 25796.430:   
[Rescan (parallel) , 0.9690640 secs]2014-02-28T23:58:50.052+0800: 25797.399:   
[weak refs processing, 0.0006190 secs]2014-02-28T23:58:50.053+0800: 25797.400: [scrub string table, 0.0006290 secs]   
[1 CMS-remark: 17355150K(23068672K)] 18720292K(24903680K), 0.9706650 secs] [Times: user=16.49 sys=0.06, real=0.97 secs]

 Rescan (parallel)表示的是多线程处理young区和多线程扫描old+perm的总时间， parallel 表示多GC线程并行。

weak refs processing 处理old区的弱引用的总时间，用于回收native memory.等等

参考资料:

 https://blogs.oracle.com/jonthecollector/entry/the_unspoken_cms_and_printgcdetails

 https://blogs.oracle.com/poonam/entry/understanding_cms_gc_logs

 4:老年代(CMS old GC ) concurrent mode failure日志 

2014-03-03T09:38:26.457+0800: 233373.804: [GC [1 CMS-initial-mark: 17319615K(23068672K)] 17351070K(24903680K), 0.0419440 secs]   
[Times: user=0.04 sys=0.00, real=0.04 secs]  
2014-03-03T09:38:26.499+0800: 233373.846: [CMS-concurrent-mark-start]  
2014-03-03T09:38:28.175+0800: 233375.522: [GC2014-03-03T09:38:28.175+0800: 233375.522: [CMS2014-03-03T09:38:28.887+0800: 233376.234:   
[CMS-concurrent-mark: 1.989/2.388 secs] [Times: user=14.37 sys=0.24, real=2.39 secs]  
 (concurrent mode failure): 17473174K->8394653K(23068672K), 19.3309170 secs] 18319691K->8394653K(24903680K),   
 [CMS Perm : 23157K->23154K(98304K)], 19.3311700 secs] [Times: user=22.18 sys=0.00, real=19.33 secs]

 concurrent mode failure一般发生在CMS GC 运行过程中,老年代空间不足，引发MSC(Full GC)

上面的这条发日志说明CMS运行到CMS-concurrent-mark过程中就出现空间不足,产生并发失败(17319615K(23068672K)占77%),

解决思路：降低YGC频率，降低CMS GC触发时机,适当降低CMSInitiatingOccupancyFraction.

 5:新生代(ParNew YGC)promotion failed日志  

2014-02-27T21:19:42.460+0800: 210095.040: [GC 210095.040: [ParNew (promotion failed): 1887487K->1887488K(1887488K), 0.4818790 secs]210095.522: [CMS: 13706434K->7942818K(23068672K), 9.7152990 secs] 15358303K->7942818K(24956160K), [CMS Perm : 27424K->27373K(98304K)], 10.1974110 secs] [Times: user=12.06 sys=0.01, real=10.20 secs]

promotion failed一般发生在新生代晋升老年代时,老年代空间不够或连续空间不够却还没达到old区的触发值,引发Full Gc.

 解决思路:由于heap碎片,YGC晋升对象过大,过长.(mid/long Time Object),调整-XX:PretenureSizeThreshold=65535,-XX:MaxTenuringThreshold=6

 6:system.gc()产生的Full GC日志 

2014-01-21T17:44:01.554+0800: 50212.568: [Full GC (System) 50212.568:   
[CMS: 943772K220K(2596864K), 2.3424070 secs] 1477000K->220K(4061184K), [CMS Perm : 3361K->3361K(98304K)], 2.3425410 secs] [Times: user=2.33 sys=0.01, real=2.34 secs]

Full GC (System)意味着这是个system.gc调用产生的MSC。

“943772K->220K(2596864K), 2.3424070 secs”表示：这次MSC前后old区内总对象大小，old的capacity及这次MSC耗时。
“1477000K->220K(4061184K)”表示：这次MSC前后JavaHeap内总对象大小，JavaHeap的capacity。
“3361K->3361K(98304K)], 2.3425410 secs”表示：这次MSC前后Perm区内总对象大小，Perm区的capacity。

解决:
使用-XX:+DisableExplicitGC参数，System.gc()会变成空调用.
如果应用有地方大量使用direct memory 或 rmi，那么使用-XX:+DisableExplicitGC要小心。
可以使用-XX:+ExplicitGCInvokesConcurrent替换把 System.gc()从Full GC换成CMS GC.

 原因:

DirectByteBuffer没有finalizer，native memory的清理工作是通过sun.misc.Cleaner自动完成
sun.misc.Cleaner是基于PhantomReference的清理工具,Full GC/Old GC会对old gen做reference processing，同时触发Cleaner对已死的DirectByteBuffer对象做清理。
如果长时间没有GC或者只做了young GC的话,不会触发old区Cleaner的工作，容易产生DirectMemory OOM.
参考:https://gist.github.com/rednaxelafx/1614952

RMI会做的是分布式GC。Sun JDK的分布式GC是用纯Java实现的,为RMI服务。 
参考:http://docs.oracle.com/javase/6/docs/technotes/guides/rmi/sunrmiproperties.html

 7:特殊的Full GC日志,根据动态计算直接进行MSC 

2014-02-13T13:48:06.349+0800: 7.092: [GC 7.092: [ParNew: 471872K->471872K(471872K), 0.0000420 secs]7.092: [CMS: 366666K->524287K(524288K), 27.0023450 secs] 838538K->829914K(996160K), [CMS Perm : 3196K->3195K(131072K)], 27.0025170 secs]

ParNew的时间特别短，jvm在minor gc前会首先确认old是不是足够大，如果不够大，这次young gc直接返回，进行MSC(Full GC)。

二:参数配置和理解

1:参数分类和说明

jvm参数分固定参数和非固定参数

1):固定参数

如：-Xmx,-Xms,-Xmn,-Xss.

2):非固定参数

如:

-XX:+<option> 启用选项

-XX:-<option> 不启用选项

-XX:<option>=<number> 给选项设置一个数字类型值，可跟单位，例如 128k, 2g

-XX:<option>=<string> 给选项设置一个字符串值，例如-XX:HeapDumpPath=./dump.log

 2:JVM可设置参数和默认值

1):-XX:+PrintCommandLineFlags

打印出JVM初始化完毕后所有跟最初的默认值不同的参数及它们的值,jdk1.5后支持.

线上建议打开，可以看到自己改了哪些值.

2):-XX:+PrintFlagsFinal

显示所有可设置的参数及"参数处理"后的默认值。参数本身只从JDK6 U21后支持

可是查看不同版本默认值,以及是否设置成功.输出的信息中"="表示使用的是初始默认值，而":="表示使用的不是初始默认值

如:jdk6/7 -XX:+MaxTenuringThreshold 默认值都是15,但是在使用CMS收集器后,jdk6默认4 , jdk7默认6. 

[hbase96 logs]# java -version  
java version "1.6.0_27-ea"  
[hbase96 logs]# java -XX:+PrintFlagsInitial | grep MaxTenuringThreshold  
intx MaxTenuringThreshold = 15 {product}  
[hbase96 logs]# java -XX:+PrintFlagsFinal -XX:+UseConcMarkSweepGC | grep MaxTenuringThreshold   
intx MaxTenuringThreshold := 4 {product}   
  
[zw-34-71 logs]# java -version  
java version "1.7.0_45"  
[zw-34-71 logs]# java -XX:+PrintFlagsInitial | grep MaxTenuringThreshold  
intx MaxTenuringThreshold = 15 {product}  
[zw-34-71 logs]# java -XX:+PrintFlagsFinal -XX:+UseConcMarkSweepGC | grep MaxTenuringThreshold  
intx MaxTenuringThreshold := 6 {product}
3):-XX:+PrintFlagsInitial

 在"参数处理"之前所有可设置的参数及它们的值,然后直接退出程序.

这里的"参数处理"指: 检查参数之间是否有冲突,通过ergonomics调整某些参数的值等. 

[hbase96 logs]# java -version  
java version "1.6.0_27-ea"  
[hbase96 logs]# java -XX:+PrintFlagsInitial | grep UseCompressedOops  
bool UseCompressedOops = false {lp64_product}   
[hbase96 logs]# java -XX:+PrintFlagsFinal | grep UseCompressedOops  
bool UseCompressedOops := true {lp64_product}
  4)CMSInitiatingOccupancyFraction 默认值是多少 

jdk6/7: 

#java -server -XX:+UseConcMarkSweepGC -XX:+PrintFlagsFinal | grep -P "CMSInitiatingOccupancyFraction|CMSTriggerRatio|MinHeapFreeRatio"  
intx CMSInitiatingOccupancyFraction            = -1              {product}         intx CMSTriggerRatio                           = 80              {product}         uintx MinHeapFreeRatio                          = 40              {product}

  计算公式:

CMSInitiatingOccupancyFraction = (100 - MinHeapFreeRatio) + (CMSTriggerRatio * MinHeapFreeRatio / 100)

最终结果: 在jdk6/7中 CMSInitiatingOccupancyFraction默认值是92% .不是网上传的68%;  都这么传,是因为 "深入理解Java虚拟机"一书中是68%,但它用的是jdk5 , jdk5的CMSTriggerRatio默认值是20,坑爹...

三:JVM内存区域理解和相关参数

一图胜千言,直接上图

1):物理分代图.

 

物理分代是除G1之外的JVM 内存分配方式,jvm 通过-Xmx,-Xmn/newRatio等参数将jvm heap划分成物理固定大小，对于不同场景比例应该设置成多少很考验经验.

一篇JVM CMS优化讲解的非常好的文章: how-tame-java-gc-pauses

 2) 逻辑分代图(G1)

逻辑分代是以后的趋势(PS:jkd8连perm都不区分了。)， 不需要使用者在纠结Xms/Xmn,SurvivorRatio等比例问题,采用动态算法调整分代大小。

转载于:https://my.oschina.net/OQKuDOtsbYT2/blog/416895

chimu9074
关注
Java启动参数设置jvm日志打印
weixin_42422362的博客
08-11 175
如何设置Java启动参数以打印JVM日志 在Java开发中，记录JVM日志是一个常见且必要的任务，特别是在出现问题时，这有助于我们追踪和调试。对于刚入行的小白来说，可能会对如何设置Java启动参数以便于记录JVM日志感到困惑。本文将指导你一步步完成这个过程，并提供详细的代码示例和注释。 整体流程概述 为了设置JVM日志打印...
深入理解jvm和jvm基本调优参数
热门推荐
congge
04-06 2万+
Java虚拟机原理 所谓虚拟机，就是一台虚拟的机器。他是一款软件，用来执行一系列虚拟计算指令，大体上虚拟机可以分为:系统虚拟机和程序虚拟机， 大名鼎鼎的Visual Box、Vmare就属于系统虚拟机，他们完全是对物理计算的仿真，提供了一个可以运行完整操作系统的软件平台。 程序虚拟机典型代码就是Java虚拟机，它专门为执行单个计算程序而计算，在Java虚拟机中执行的指令我们成为Java自己码指令。...
jvm内存分配和日志分析
myloveinnocence的博客
03-01 723
文章目录前言一、新生代和老年代比例二、jdk8默认垃圾收集器三、jvm 参数设置四、jvm 日志分析总结 前言 提示：这里可以添加本文要记录的大概内容： 例如：随着人工智能的不断发展，机器学习这门技术也越来越重要，很多人都开启了学习机器学习，本文就介绍了机器学习的基础内容。 提示：以下是本篇文章正文内容，下面案例可供参考 一、新生代和老年代比例 堆大小 = 新生代 + 老年代。其中，堆的大小可以通过参数 –Xms、-Xmx 来指定。 默认的，新生代 ( Young ) 与老年代 ( Old ) 的比例的
JVM 常见配置参数
tian830937的专栏
05-27 3471
JVM 配置常见参数Java虚拟机的参数，在启动jar包的时候通过java 命令指定JVM参数-options表示Java虚拟机的启动参数，class为带有main()函数的Java类，args表示传递给主函数main()的参数。
JVM的GC日志的主要参数
懂哥的博客
09-17 1143
-Xmn1024m -Xms2500m -Xmx2500m -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:MaxDirectMemorySize=256m -XX:+UseCMSInitiatingOccupancyOnly -XX:SurvivorRatio=8 -XX:+ExplicitGCInvok...
JVM OOM异常和参数说明
Charge8的博客
08-06 1408
JVM OOM异常和参数说明
JVM 常用的参数说明与配置指南
fhey的博客
07-31 4086
在 Java 应用的运行中，合理配置 JVM 参数对于系统的性能优化和稳定运行至关重要。本文详细介绍了常见的 JVM 参数，包括模式参数、堆内存参数、垃圾回收器参数、日志打印参数、dump 日志参数等，并提供了不同内存大小下的参数设置示例和模板，帮助您更好地理解和配置 JVM 参数，以提升 Java 应用的性能和可靠性。本文全面涵盖了 JVM 参数的各个方面，从模式选择到具体的堆内存、垃圾回收器、日志打印和 dump 日志等参数的配置。
【深入理解JVM】详解GC日志参数配置及日志分析
程序员云帆哥的博客
07-31 4542
一、首先模拟一个JVM堆内存不足的异常场景。 public class GCTest { public static void main(String[] args) { List<Object> d = new ArrayList<Object>(); while(true){ d.add(new GCTest()); } }...
从ES的JVM配置起步思考JVM常见参数优化
张彦峰的博客
06-13 2万+
Java 8目前仍然是许多企业中主要使用的版本之一，尤其是对于比较保守的公司。在过去，CMS (Concurrent Mark-Sweep) 垃圾回收器在Java 8中是一种常见选择，因为它在某些场景下能够提供较好的性能。然而，随着Java版本的不断更新，一些旧的特性和组件被淘汰或替代，比如CMS。Java 14中正式废弃了CMS，而新的垃圾回收器，如ZGC和G1，逐渐成为了主流选择。ZGC和G1在处理大内存堆和低停顿时间方面表现出色，适用于现代应用程序的需求。
jvm参数设置_JVM参数设置_
10-02
- `-XX:+TraceClassLoading`：跟踪类加载信息，有助于调试和理解类加载过程。 7. 编译优化： - `-XX:+TieredCompilation`：启用分层编译，提高代码优化的速度。 - `-XX:CompileThreshold`：设定方法触发即时编译...
jvm crash的崩溃日志详细分析及注意点
08-30
总之，理解和分析JVM崩溃日志是诊断和解决Java应用程序性能问题的关键步骤。通过深入研究日志内容，我们可以找到可能导致崩溃的原因，从而采取相应的优化措施或修复代码，确保应用的稳定性和可靠性。
jvmgc日志分析工具
03-20
GC日志分析工具是用来理解和优化JVM内存管理的重要工具。"jvmgc日志分析工具"专为解析和可视化JVM生成的GC日志而设计，帮助开发者识别内存瓶颈，调整内存设置，以及诊断可能的性能问题。 GC日志是JVM在运行过程中...
JVM 参数配置详细介绍
08-31
Java虚拟机（JVM）是Java程序运行的基础，它的参数配置对于优化应用程序的性能至关重要。以下是对JVM参数配置的详细说明： ...理解这些参数的含义并合理配置，对于解决性能问题和避免内存相关错误至关重要。
大数据学习10之Hive高级
qq_64407249的博客
11-06 1595
过程：创建Maven项目，导入依赖，创建方法类，并继承响应方法类实现方法类的方法生成jar包Hive导入自定义函数jar包重新加载函数。
Kafka生产者如何提高吞吐量？
wadjdkdkdjjd的博客
11-09 473
②在 IDEA 中执行代码，观察 hadoop102 控制台中是否接收到消息。4、 RecordAccumulator：缓冲区大小，修改为64m。2、linger.ms：等待时间，修改为5-100ms。3、compression.type：压缩snappy。①在 bigdata01 上开启 Kafka 消费者。1、batch.size：批次大小，默认16k。
Python 自动化运维数据湖与大数据平台的自动化管理
switch616的博客
11-11 885
数据湖的架构通常由多个层次组成，包括数据接入层、数据存储层、数据处理层和数据消费层。数据接入层：这一层负责将不同来源的数据采集到数据湖中。数据源可以是日志文件、数据库、外部API等。接入层需要保证数据的稳定流入，同时也需要对接入的数据进行清洗和转换。数据存储层：数据湖通常使用分布式存储系统（如Hadoop HDFS、Amazon S3等）来存储海量数据。运维人员需要确保存储系统的高可用性、数据备份和恢复的能力。数据处理层：数据湖中的数据需要经过ETL（提取、转换、加载）处理。
大数据机器学习算法与计算机视觉应用02：线性规划
最新发布
qq_35933041的博客
11-12 800
在零和博弈中，是概率和对应收益乘积的总和（收益给定），在最大流问题中，是通往终点所有流量的总和。卡马卡方法又被称作内部点方法，它寻找最优解的方法并非从可行域边界的一个顶点出发，而是从可行域内部的一个点开始。线性规划可以是没有边界的，但是一般都是可行的，否则目标函数无解。单纯形法从可行域的一个顶点开始，依次和附近的点比较，如果发现新的最大值，就进行迁移。在许多情况下，这个方程是没有精确解的，这个时候我们转而去计算最接近的解，也就是要求。的交点上，那么其中一个在最新的这一步出现的概率是多少呢？
（六）Spark大数据开发实战：豆瓣电影数据处理与分析（scala版）
weixin_44458771的博客
11-12 897
本项目对电影信息数据进行处理和分析，实现了对电影演员、电影类型、上映时间等多维度的统计分析。同时考察了DataFrame操作、Spark SQL操作、聚合与数据转换、窗口函数、日期和时间处理、数据清洗、写入写出等等。 由于Scala是直接运行在JVM上，因此它的运行速度通常比Python快。经测试，本项目的scala版本代码运行总用时22.8秒，而python版本代码运行总用时24.6秒，scala运行比python稍快一点，总的来说相差不大，在大规模数据量的项目中，scala的优势会更加明显。
深入理解JVM：关键配置参数与GC日志解析
通过这些参数，开发者可以更深入地理解和优化JVM的性能。" 在Java开发中，JVM配置参数对于应用程序的性能调优至关重要。以下是一些重要的JVM配置参数及其作用： 1. **Trace跟踪参数**： - `-verbose:gc`：这个...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值