jvm的GC日志分析

最新推荐文章于 2024-05-27 16:10:53 发布
最新推荐文章于 2024-05-27 16:10:53 发布
阅读量542 收藏 1
点赞数
分类专栏： JVM 文章标签： JVM GC 日志
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/johnf_nash/article/details/83833012
版权

一、GC 类型

Java中的GC有哪几种类型？

参数描述
UseSerialGC虚拟机运行在Client模式的默认值，打开此开关参数后，使用Serial+Serial Old收集器组合进行垃圾收集
UseParNewGC打开此开关参数后，使用ParNew+Serial Old收集器组合进行垃圾收集
UseConcMarkSweepGC打开此开关参数后，使用ParNew+CMS+Serial Old收集器组合进行垃圾收集。Serial Old作为CMS收集器出现Concurrent Mode Failure的备用垃圾收集器
UseParallelGC虚拟机运行在Server模式的默认值，打开此开关参数后，使用Parallel Scavenge+Serial Old收集器组合进行垃圾收集。
UseParallelOldGC打开此开关参数后，使用Parallel Scavenge+Parallel Old收集器组合进行垃圾收集
UseG1GC代开此开关参数后，使用G1垃圾收集器进行垃圾收集

在Java程序启动完成后，通过jps观察进程来查询到当前运行的java进程，使用

jinfo –flag UseSerialGC pid

的方式可以定位其使用的gc策略，因为这些参数都是boolean型的常量，如果使用该种gc策略会出现＋号，否则－号。

使用-XX:+上述GC策略可以开启对应的GC策略。

二、 GC日志主要参数

JVM的GC日志的主要参数包括如下几个：

-XX:+PrintGC 输出GC日志

-XX:+PrintGCDetails 输出GC的详细日志

-XX:+PrintGCTimeStamps 输出GC的时间戳（以基准时间的形式）

-XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）

-XX:+PrintHeapAtGC 在进行GC的前后打印出堆的信息

-XX:+PrintTenuringDistribution 输出显示在survivor空间里面有效的对象的岁数情况

-XX:+PrintGCApplicationStoppedTime // 输出GC造成应用暂停的时间

-Xloggc:../logs/gc.log 日志文件的输出路径 (可以使用绝对路径或者相对路径)

三、常用JVM参数

分析gc日志后，经常需要调整jvm内存相关参数，常用参数如下

-Xms：初始堆大小；默认(MinHeapFreeRatio参数可以调整)空余堆内存小于40%时，
 	  JVM就会增大堆直到-Xmx的最大限制 (对应 InitialHeapSize 设置)

-Xmx：最大堆大小，默认(MaxHeapFreeRatio参数可以调整)空余堆内存大于70%时，JVM会减少堆直到 -Xms的最小限制
	（对应 MaxHeapSize 设置)

-Xmn：新生代的内存空间大小，注意：此处的大小是（eden+ 2 survivor space)。与jmap -heap中显示的New gen是不同的。
	  整个堆大小=新生代大小 + 老生代大小 + 永久代大小。 
	  在保证堆大小不变的情况下，增大新生代后,将会减小老生代大小。
	  此值对系统性能影响较大,Sun官方推荐配置为整个堆的3/8。

-XX: SurvivorRatio：新生代中Eden区域与Survivor区域的容量比值，默认值为8。
	 两个Survivor区与一个Eden区的比值为2:8,一个Survivor区占整个年轻代的1/10。

-Xss：每个线程的堆栈大小。JDK5.0 以后每个线程堆栈大小为1M,以前每个线程堆栈大小为256K。
	  应根据应用的线程所需内存大小进行适当调整。在相同物理内存下,减小这个值能生成更多的线程。
	  一般小的应用， 如果栈不是很深， 应该是128k够用的，大的应用建议使用256k。
	  (对应 ThreadStackSize 设置)。

-XX:PermSize：设置永久代(perm gen)初始值 （JDK 1.8 中已经不再支持）。

-XX:MaxPermSize：设置持久代最大值 （JDK 1.8 中已经不再支持）。

-XX:MetaspaceSize：设置元空间（Meta Space）初始值（JDK 1.8 中新增）

-XX:MaxMetaspaceSize： 设置元空间（Meta Space）的最大值（JDK 1.8 新增）

四、GC 日志实例

1、 Serial GC 日志实例

测试代码如下：

import java.util.ArrayList;
import java.util.List;

public class HeapOOM {

	static class OOMObject {
		byte[] b = new byte[1024 * 1024];
	}

	public static void main(String[] args) {
		int count = 0;
		List<OOMObject> list = new ArrayList<OOMObject>();
		try {
			while(count < 20) {
				list.add(new OOMObject());
				Thread.sleep(200);
				count++;
			}
		} catch (Throwable e) {
			e.printStackTrace();
		} finally {
			System.out.println("count: " + count);
		}
	}
	
}

JVM 参数：

-XX:+PrintGCDetails  -XX:+PrintGCTimeStamps -Xloggc:./gc.log -Xms20m -Xmx20m

运行结果如下：

count: 17
java.lang.OutOfMemoryError: Java heap space
	at com.johnfnash.learn.jvm.mem.HeapOOM$OOMObject.<init>(HeapOOM.java:12)
	at com.johnfnash.learn.jvm.mem.HeapOOM.main(HeapOOM.java:20)

查看 gc 日志：

Java HotSpot(TM) Client VM (25.171-b11) for windows-x86 JRE (1.8.0_171-b11)
......

2.646: [GC (Allocation Failure) 2.646: [DefNew: 4830K->496K(6144K), 0.0119400 secs] 4830K->4592K(19840K), 0.0124441 secs] [Times: user=0.02 sys=0.00, real=0.02 secs] 
3.743: [GC (Allocation Failure) 3.743: [DefNew: 5725K->0K(6144K), 0.0126833 secs] 9821K->9711K(19840K), 0.0129225 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
4.765: [GC (Allocation Failure) 4.765: [DefNew: 5221K->5221K(6144K), 0.0000545 secs]4.765: [Tenured: 9711K->12784K(13696K), 0.0214370 secs] 14933K->14832K(19840K), [Metaspace: 80K->80K(4480K)], 0.0227165 secs] [Times: user=0.01 sys=0.00, real=0.01 secs] 
5.405: [Full GC (Allocation Failure) 5.405: [Tenured: 12784K->12784K(13696K), 0.0041136 secs] 18007K->17904K(19840K), [Metaspace: 80K->80K(4480K)], 0.0043785 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
5.410: [Full GC (Allocation Failure) 5.410: [Tenured: 12784K->12772K(13696K), 0.0095670 secs] 17904K->17892K(19840K), [Metaspace: 80K->80K(4480K)], 0.0097671 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
Heap
 def new generation   total 6144K, used 5320K [0x03e00000, 0x044a0000, 0x044a0000)
  eden space 5504K,  96% used [0x03e00000, 0x04332390, 0x04360000)
  from space 640K,   0% used [0x04360000, 0x04360000, 0x04400000)
  to   space 640K,   0% used [0x04400000, 0x04400000, 0x044a0000)
 tenured generation   total 13696K, used 12772K [0x044a0000, 0x05200000, 0x05200000)
   the space 13696K,  93% used [0x044a0000, 0x051191e8, 0x05119200, 0x05200000)
 Metaspace       used 81K, capacity 2244K, committed 2368K, reserved 4480K

最前面的数字 “2.646：” 和 “5.045：” 代表了 GC 发生时间，这个数字的含义是从 Java 虚拟机启动以来经过的秒数。

GC 日志开头的 “[GC” 和 “[Full GC” 说明了这次垃圾收集的停顿类型，而不是用来区分新生代GC还是老年代GC。如果有“Full”，说明这次GC是发生了 Stop-The-World 的，例如下面这段新生代收集器 Serial 的日志也会出现“[Full GC”（这一般是因为出现了分配担保失败之类的问题，所以才导致 STW）。这里的 “(Allocation Failure) ” 是引起垃圾回收的原因，本次GC是因为年轻代中没有任何合适的区域能够存放需要分配的数据而触发的。如果是调用 System.gc() 方法锁触发的收集，那么在这里将显示“[Full GC(System.gc())”。

5.405: [Full GC (Allocation Failure) 5.405: [Tenured: 12784K->12784K(13696K), 0.0041136 secs]

接下来的“[DefNew”、“[Tenured”、“[Metaspace” 表示GC发生的区域，这里显示的区域名称与使用的GC收集器是密切相关的，例如上面样例使用的 Serial 收集器中的新生代名为“Default New Generation”，所以显示的是“[DefNew”。如果是 ParNew 收集器，新生代名称就会变为“[ParNew”，意为“Parallel New Generation”。如果采用 Parallel Scavenge 收集器，那它配套的新生代成为“PSYoundGen”，老年代和永久代同理，名称也是有收集器决定的。
(注意，这里的 def new generation 只包含 eden + from survivor，整个新生代则包含 eden + from survivor + to survivor)

后面方括号内部的“4830K->496K(6144K)”含义是“GC前该区域已使用容量 -> GC 后该内存区域已使用容量（该内存区域总容量）”。而在方括号之外的“4830K->4592K(19840K)” 表示“GC 前 Java 堆已使用容量 -> GC 后 Java 堆已使用容量（Java 堆总容量）”。

再往后，“0.0124441 secs”表示该内存区域 GC 所占用的时间，单位是秒。有的收集器会给出更具体的时间数据，如“[Times : user=0.01 sys=0.00, real=0.02 secs]”，这里面的 user、sys 和 real 与Linus 的time命令所输出的时间含义一致，分别代表用户态消耗的CPU时间、内核态小号的 CPU 事件和操作从开始到结束所经过的墙钟时间（Wall Clock Time）。CPU时间与墙钟时间的区别是，墙钟时间包括各种非运算的等待耗时，例如等待磁盘I/O、等待线程阻塞，而CPU时间不包括这些耗时，但当系统有多 CPU 或者多核的话，多线程操作会叠加这些 CPU 时间，所以读者看到 user 或者 sys 时间超过 real 时间是完全正常的。

另外，

[0x03e00000, 0x044a0000, 0x044a0000)

这种形式的日志有两种意义：

当这种日志出现在generation的详细信息里的时候，三个数字在HotSpot里分别称为low_boundary、high、high_boundary。

low_boundary: reserved space的最低地址边界；通常也跟“low”相等，这是commited space的最低地址边界 

high: commited space的最高地址边界 

high_boundary: reserved space的最高地址边界。

[low_boundary, high_boundary) 范围内的就是reserved space，这个space的大小就是max capacity。

[low, high)范围内的就是commited space，而这个space的大小就是current capacity（当前容量），简称capacity。

capacity有可能在一对最小值和最大值之间浮动。最大值就是上面说的max capacity。

-XX:+PrintTenuringDistribution 与 -XX:MaxTenuringThreshold
-XX:+PrintGCDetails
-XX:+PrintHeapAtGC
-XX:+PrintGCDateStamps
-XX:+PrintTenuringDistribution
-verbose:gc
-Xloggc:gc.lo

后可以看到进行GC前后的堆内存信息

{Heap before GC invocations=0 (full 0):
 def new generation   total 6144K, used 4830K [0x03800000, 0x03ea0000, 0x03ea0000)
  eden space 5504K,  87% used [0x03800000, 0x03cb79f0, 0x03d60000)
  from space 640K,   0% used [0x03d60000, 0x03d60000, 0x03e00000)
  to   space 640K,   0% used [0x03e00000, 0x03e00000, 0x03ea0000)
 tenured generation   total 13696K, used 0K [0x03ea0000, 0x04c00000, 0x04c00000)
   the space 13696K,   0% used [0x03ea0000, 0x03ea0000, 0x03ea0200, 0x04c00000)
 Metaspace       used 79K, capacity 2244K, committed 2368K, reserved 4480K
1.134: [GC (Allocation Failure) 1.145: [DefNew
Desired survivor size 327680 bytes, new threshold 1 (max 15)
- age   1:     508840 bytes,     508840 total
: 4830K->496K(6144K), 0.0145337 secs] 4830K->4592K(19840K), 0.0259003 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 
Heap after GC invocations=1 (full 0):
 def new generation   total 6144K, used 496K [0x03800000, 0x03ea0000, 0x03ea0000)
  eden space 5504K,   0% used [0x03800000, 0x03800000, 0x03d60000)
  from space 640K,  77% used [0x03e00000, 0x03e7c3a8, 0x03ea0000)
  to   space 640K,   0% used [0x03d60000, 0x03d60000, 0x03e00000)
 tenured generation   total 13696K, used 4096K [0x03ea0000, 0x04c00000, 0x04c00000)
   the space 13696K,  29% used [0x03ea0000, 0x042a0040, 0x042a0200, 0x04c00000)
 Metaspace       used 79K, capacity 2244K, committed 2368K, reserved 4480K
}

...

{Heap before GC invocations=3 (full 1):
 def new generation   total 6144K, used 5223K [0x03800000, 0x03ea0000, 0x03ea0000)
  eden space 5504K,  94% used [0x03800000, 0x03d19fe0, 0x03d60000)
  from space 640K,   0% used [0x03d60000, 0x03d60000, 0x03e00000)
  to   space 640K,   0% used [0x03e00000, 0x03e00000, 0x03ea0000)
 tenured generation   total 13696K, used 12784K [0x03ea0000, 0x04c00000, 0x04c00000)
   the space 13696K,  93% used [0x03ea0000, 0x04b1c008, 0x04b1c200, 0x04c00000)
 Metaspace       used 80K, capacity 2244K, committed 2368K, reserved 4480K
3.864: [Full GC (Allocation Failure) 3.864: [Tenured: 12784K->12784K(13696K), 0.0043278 secs] 18007K->17904K(19840K),
 [Metaspace: 80K->80K(4480K)], 0.0050660 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap after GC invocations=4 (full 2):
 def new generation   total 6144K, used 5120K [0x03800000, 0x03ea0000, 0x03ea0000)
  eden space 5504K,  93% used [0x03800000, 0x03d00138, 0x03d60000)
  from space 640K,   0% used [0x03d60000, 0x03d60000, 0x03e00000)
  to   space 640K,   0% used [0x03e00000, 0x03e00000, 0x03ea0000)
 tenured generation   total 13696K, used 12784K [0x03ea0000, 0x04c00000, 0x04c00000)
   the space 13696K,  93% used [0x03ea0000, 0x04b1c008, 0x04b1c200, 0x04c00000)
 Metaspace       used 80K, capacity 2244K, committed 2368K, reserved 4480K
}

...

java.lang.OutOfMemoryError: Java heap space
count: 17
	at com.johnfnash.learn.jvm.mem.HeapOOM$OOMObject.<init>(HeapOOM.java:12)
	at com.johnfnash.learn.jvm.mem.HeapOOM.main(HeapOOM.java:20)
Heap
 def new generation   total 6144K, used 5320K [0x03800000, 0x03ea0000, 0x03ea0000)
  eden space 5504K,  96% used [0x03800000, 0x03d32390, 0x03d60000)
  from space 640K,   0% used [0x03d60000, 0x03d60000, 0x03e00000)
  to   space 640K,   0% used [0x03e00000, 0x03e00000, 0x03ea0000)
 tenured generation   total 13696K, used 12772K [0x03ea0000, 0x04c00000, 0x04c00000)
   the space 13696K,  93% used [0x03ea0000, 0x04b191e8, 0x04b19200, 0x04c00000)
 Metaspace       used 81K, capacity 2244K, committed 2368K, reserved 4480K

其中-XX:+PrintTenuringDistribution只是丰富了gclog部分如下,用户输出显示在survivor空间里面有效的对象的岁数情况：

格式：- age 年龄: 处于当前年龄段的对象大小 总大小(各个年龄段是累计的)

Desired survivor size 327680 bytes, new threshold 1 (max 15)
- age   1:     508840 bytes,     508840 total
: 4830K->496K(6144K), 0.0145337 secs

描述信息：

这个情况是survivor空间溢出，survivor空间被占满，然后溢出的部分，直接放到了年老代（4830K - 496K = 4334K），溢出之后，计算survivor空间里头对象的年龄分布，发现年龄为1的对象大小总和超过了survivor的desired值，于是设置新的阈值为该age=1。（每次young gc之后打印survivor区域内对象的年龄分布）

如果底下age的total大小大于Desired survivor size的大小，那么就代表了survivor空间溢出了，被填满，然后会重新计算threshold。
其中 Desired survivor size 327680 bytes 是 Survivor空间大小 * 目标存活率（-XX:TargetSurvivorRatio, 可以设定，默认50%）

注：

  1. -XX:TargetSurvivorRatio: 目标存活率，默认为50%, 表明在survivor space中相同age的对象大小总和如果超过Desired survivor size，
    则重新计算threshold，以age 和 MaxTenuringThreshold的最小值为准，否则以MaxTenuringThreshold为准。
    此时，年龄大于或者等于计算出的thread的对象就直接进入老年代。

  2. -XX:MaxTenuringThreshold设置过大问题：原本应该晋升对象到survivor区,直到survivor区溢出，一旦溢出发生，Eden+Svuvivor中对象将不再依据年龄全部提升到老年代，这样对象老化的机制就失效了

    -XX:MaxTenuringThreshold设置过小：eden区的对象会陆续送入old区，对象移动本身就是开销，cms老年代回收还会造成碎片化。

参考

  1. jvm的GC日志分析

  2. Survivor空间溢出实例

  3. jvm-对象年龄(-XX:+PrintTenuringDistribution)

xxc1605629895
关注
专栏目录
JVM——GC日志实战分析
庄小焱
12-01 2861
博文将具体示例来演示如何输出 GC 日志，并对输出的日志信息进行解读分析，从中提取有用的信息。
JVM系列之：日志分析工具：GCViewer、VisualVM、GCeasy
weixin_45987961的博客
04-01 1611
GCViewer GCViewer 是一个可以将 JVM 中的 gc log 可视化的工具，使用该工具可以帮助你充分的发现 JVM 垃圾回收中的潜在问题，让你可以更加准确的做出关于 JVM GC 优化的决策。 安装并启动 git clone https://github.com/chewiebug/GCViewer.git //或者用 IDEA打开项目后，用 maven进行打包 mvn clean pacakge //得到一个 jar包 cd target java -jar gcvie...
程序员快乐之GC日志分析实战
weixin_30484149的博客
10-24 232
阅读GC日志是处理Java虚拟机内存问题的基础技能，然而GC日志仅仅是认为确定的规则，倒是没有什么技术含量，和分析排查自己系统线上错误日志基本类似。 1.如何打印GC日志 打印GC日志非常简单，只要配置一下GC打印参数即可，接下来通过一个程序来看看如何查看GC日志。 1.1编写测试程序 /** * @Description:GC日志打印与OOM测试 */ public class GcLogDemo { public static void main(String[] args) .
JVM之GC日志
weixin_44742132的博客
07-18 158
出自抽象写实派大作家本人之手：happy 2nd anniversary ~happy？happy个狗~❝JVM 相关的理论知识网上已经被讲的比较详细了，但是，不管是日常工作或是面试考察...
JVM 配置GC日志
egegerhn的博客
08-18 2165
通过-XX:+UseGCLogfileRotation -XX:NumberOfGCLogfiles=N -XX:GCLogfileSize=N标志可以控制日志文件的循环。多种方法都能开启GC的日志功能，其中包括：使用-verbose:gc或-XX:+PrintGC这两个标志中的任意一个能创建基本的GC日志。除了使用详细的GC日志，我们还推荐使用-XX:+PrintGCTimeStamps或者-XX:+PrintGCDateStamps，由于日期戳需要进行格式化，所以它的效率可能会受轻微的影响，...
JVM的GC日志分析
泡^泡
02-22 532
JVM的GC日志分析
JVM性能调优之GC日志分析
qq_39093474的博客
09-01 2654
1.为什么需要GC日志 Java虚拟机GC日志是用于定位问题重要的日志信息，频繁的GC可能导致应用吞吐量下降，响应时间增加，甚至导致服务不可用。所以需要我们对GC日志进行分析并优化。 2. 如何开启GC日志 我们可以在JVM中设置参数-XX:+PrintGC或者-verbose:gc，默认GC日志是关闭的，但是如果想输出GC详细的日志，可以增加其他的辅助参数。可以根据自己的需求增加。 注意：GC的日志是以替换的方式(>)写入的，而不是追加(>>)，如果下次写入到同一个文件中的话，以前
jvmgc日志分析工具
03-20
"jvmgc日志分析工具"专为解析和可视化JVM生成的GC日志而设计，帮助开发者识别内存瓶颈，调整内存设置，以及诊断可能的性能问题。 GC日志是JVM在运行过程中记录的关于垃圾收集活动的详细信息，包括垃圾收集的起始...
linux jvm gc日志分析,JVM GC 日志详解
weixin_29711471的博客
05-01 1152
本文采用的JDK版本：java version "1.8.0_144"Java(TM) SE Runtime Environment (build 1.8.0_144-b01)Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode)一、GC 日志参数设置JVM GC格式日志的主要参数包括如下8个：-XX:+PrintGC 输出...
linux jvm gc日志分析,JVM之GC统计以及日志分析
weixin_39634985的博客
05-01 1054
环境&准备代码JDK环境openjdk version "1.8.0_191"编写一段代码，循环声明对象，并分配 10MB 堆空间，暴露web接口多次调用。for (int i = 0; i < 100; i++) {byte[] b1 = new byte[1024 * 1024 * 10];byte[] b2 = new byte[1024 * 1024 * 10];byte[]...
JVM性能调优——GC日志分析
码说芯语的博客
04-13 3364
生成GC日志、Parallel垃圾收集器日志解析、G1垃圾收集器日志解析、CMS垃圾收集器日志解析、日志解析工具
jvm gc日志
qq_41633199的博客
05-24 240
java -Xms100m -Xmx600m -XX:+UseG1GC -XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:gc.log -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=4M -XX:+UseGCLogFileRotation -jar iic-ssp-mgr-0.0.1-SNAPSHOT.war;
JVM-之GC日志
最新发布
tian830937的专栏
05-27 1752
在项目中开启GC 日志打印后会查看gc 日志如下gc日志如下在项目中如果需要查看使用的垃圾收集器出了使用GC 日志中去分析还可以使用如下命令。
查看JVM的GC日志
男人要霸气的博客
07-02 608
文章目录Java GC类型GC日志查看GC日志的离线分析GC日志的在线分析GC垃圾回收器详解 Java GC类型 Java中的GC有哪几种类型？ 参数 描述 UseSerialGC 虚拟机运行在Client模式的默认值，打开此开关参数后，使用Serial+Serial Old收集器组合进行垃圾收集。 UseParNewGC 打开此开关参数后，使用ParNew+Serial Old收集器组合进行垃圾收集。 UseConcMarkSweepGC 打开此开关参数后，使用ParNew+CMS
JVM查看GC日志
cristianoxm的博客
04-23 5026
一、如何打印出JVM GC日志 需要在系统的JVM参数中加入GC日志的打印选型，jvm参数如下所示： -XX:NewSize=5242880 -XX:MaxNewSize=5242880 -XX:InitialHeapSize=10485760 -XX:MaxHeapSize=10485760 -XX:SurvivorRatio=8 -XX:PretenureSizeThreshold=10485760 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+Print
JVM学习之GC日志
每每看到代码，就会有亲切之感！
08-30 490
-XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:d:/gc_log/gc.log package com.tets; public class ReferenceCountingGC { public Object instance = null; private static final int _1MB =
JVM学习笔记_GC日志
dcj199411的专栏
04-16 170
每种收集器的日志形式由他们自身的实现决定，虚拟机设计者为了方便用户阅读，将各个收集器的日志维护了一定的公共性。 打印GC日志 以下GC日志通过设置JVM启动参数产生，JVM启动参数如下： -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 Java运行程序： public class MyTest1 { public static void main(String[] args) {
理解JAVA GC日志：优化JVM参数与分析技巧
通过分析GC日志，我们可以获取以下关键信息： 1. **GC频率**：观察年轻代和老年代的GC次数，如果频率过高，可能表示内存分配不合理或者有内存泄漏。 2. **GC耗时**：记录每次GC的时间，长时间的GC可能会导致应用...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值