频繁gc是什么意思_[转]一个GC频繁的Case

最新推荐文章于 2023-10-13 11:11:50 发布
最新推荐文章于 2023-10-13 11:11:50 发布
阅读量373 收藏
点赞数
文章标签： 频繁gc是什么意思
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_39885383/article/details/111763146
版权

前两天碰到一个很诡异的GC频繁的现象，走了不少弯路，N种方法查找后才终于查明原因了，在这篇blog中记录下，以便以后碰到这类问题时能更快的解决。

前两天一位同学找到我，说有个应用在启动后就一直Full GC，拿到GC

log先看了下，确实是非常的诡异，截取的部分log如下：

2011-07-16T14:55:57.733+0800: 174042.063: [Full GC [PSYoungGen:

786432K->0K(917504K)] [ParOldGen:

728400K->728457K(1048576K)]

1514832K->728457K(1966080K) [PSPermGen:

84814K->84812K(262144K)], 1.5426550 secs] [Times:

user=4.58 sys=0.21, real=1.54 secs]

2011-07-16T14:56:07.144+0800: 174051.475: [Full GC [PSYoungGen:

786432K->0K(917504K)] [ParOldGen:

728457K->728611K(1048576K)]

1514889K->728611K(1966080K) [PSPermGen:

84814K->84812K(262144K)], 1.5428850 secs] [Times:

user=4.57 sys=0.17, real=1.54 secs]

2011-07-16T14:56:16.699+0800: 174061.030: [Full GC [PSYoungGen:

786432K->0K(917504K)] [ParOldGen:

728611K->729096K(1048576K)]

1515043K->729096K(1966080K) [PSPermGen:

84814K->84812K(262144K)], 1.5064200 secs] [Times:

user=4.36 sys=0.21, real=1.50 secs]

2011-07-16T14:56:26.420+0800: 174070.750: [Full GC [PSYoungGen:

786432K->0K(917504K)] [ParOldGen:

729096K->729654K(1048576K)]

1515528K->729654K(1966080K) [PSPermGen:

84814K->84812K(262144K)], 1.5519220 secs] [Times:

user=4.47 sys=0.18, real=1.54 secs]

2011-07-16T14:56:35.634+0800: 174079.965: [Full GC [PSYoungGen:

786432K->0K(917504K)] [ParOldGen:

729654K->728743K(1048576K)]

1516086K->728743K(1966080K) [PSPermGen:

84814K->84812K(262144K)], 1.5002720 secs] [Times:

user=4.67 sys=0.11, real=1.50 secs]

2011-07-16T14:56:45.938+0800: 174090.269: [Full GC [PSYoungGen:

786432K->0K(917504K)] [ParOldGen:

728743K->729132K(1048576K)]

1515175K->729132K(1966080K) [PSPermGen:

84814K->84812K(262144K)], 1.6175360 secs] [Times:

user=4.47 sys=0.25, real=1.61 secs]

2011-07-16T14:56:55.682+0800: 174100.012: [Full GC [PSYoungGen:

786432K->0K(917504K)] [ParOldGen:

729132K->728950K(1048576K)]

1515564K->728950K(1966080K) [PSPermGen:

84814K->84812K(262144K)], 1.5780950 secs] [Times:

user=4.50 sys=0.07, real=1.58 secs]

2011-07-16T14:57:05.228+0800: 174109.559: [Full GC [PSYoungGen:

786408K->0K(917504K)] [ParOldGen:

728950K->729466K(1048576K)]

1515359K->729466K(1966080K) [PSPermGen:

84814K->84812K(262144K)], 1.5868130 secs] [Times:

user=4.43 sys=0.09, real=1.60 secs]

2011-07-16T14:57:14.812+0800: 174119.142: [Full GC [PSYoungGen:

786432K->0K(917504K)] [ParOldGen:

729466K->729277K(1048576K)]

1515898K->729277K(1966080K) [PSPermGen:

84814K->84812K(262144K)], 1.5460140 secs] [Times:

user=4.44 sys=0.19, real=1.54 secs]

这个日志中诡异的地方在于每次Full GC的时候旧生代都还有很多的空间，于是去看来下启动参数，此时的启动参数如下：

-Xmx2048m -Xms2048m -Xmn1024m -Xss512k -XX:PermSize=256m

-XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC

-XX:MaxGCPauseMillis=100 -XX:+UseAdaptiveSizePolicy

-XX:+DisableExplicitGC

可以看到，这个启动参数有很多的问题，最重要的在于MaxGCPauseMillis，因为目前版本的jdk其实很难做到达成这个目标，于是猜测可能是这个参数造成的，顺带把启动参数简单修改了下：

-Xmx2g -Xms2g -Xmn1g -Xss512k -XX:PermSize=256m

-XX:+UseParallelOldGC -XX:+DisableExplicitGC

修改完毕，重新启动了一台，发现OK了，于是认为就是这个参数造成的，可惜的是后面又重启了几次后，还是出现了GC频繁的现象。

从GC日志来看，Full

GC是在旧生代没满的情况下就频繁触发，以前有碰到过一个现象是代码中死循环，导致会GC频繁，于是先jmap -histo

[pid]看了下，char数组占用的比较多一些，但也是正常现象。

还有可能是程序中有地方在分配巨大的对象，导致新生代放不下，旧生代剩余的空间也放不下，于是想通过jstack先看看程序现在在干嘛，于是jstack了很多次程序的状况，杯具的是什么异常状况都没发现。

jstack中无法发现，于是决定通过pstack来看看c堆栈上的allocate的状况，想从此来关联到java的线程堆栈，多次执行pstack

[pid] | grep ‘allocate’后，看到了一些信息：

11284-#8 0x000000329b8d3c2d in clone () from /lib64/libc.so.6

11341-Thread 259 (Thread 0x40b25940 (LWP 20346)):

11385-#0 0x000000329c40ab99 in pthread_cond_wait@@GLIBC_2.3.2

()

11445-#1 0x00002b57b7843727 in os::PlatformEvent::park ()

11498-#2 0x00002b57b781c7c2 in Monitor::IWait ()

11542-#3 0x00002b57b781cf8e in Monitor::wait ()

11585-#4 0x00002b57b75e6aa2 in WaitForBarrierGCTask::wait_for

()

11645-#5 0x00002b57b7887d8b in PSParallelCompact::marking_phase

()

11707-#6 0x00002b57b7886e11 in PSParallelCompact::invoke_no_policy

()

11772-#7 0x00002b57b788d296 in PSScavenge::invoke ()

11820:#8 0x00002b57b7855d7e in

ParallelScavengeHeap::failed_mem_allocate ()

11891-#9 0x00002b57b796b379 in VM_ParallelGCFailedAllocation::doit

()

11956-#10 0x00002b57b7977d0a in VM_Operation::evaluate ()

12008-#11 0x00002b57b79772b2 in VMThread::evaluate_operation

()

12066-#12 0x00002b57b7977534 in VMThread::loop ()

12110-#13 0x00002b57b797702e in VMThread::run ()

12153-#14 0x00002b57b7843f9f in java_start ()

12193-#15 0x000000329c4064a7 in start_thread () from

/lib64/libpthread.so.0

12263-#16 0x000000329b8d3c2d in clone () from

/lib64/libc.so.6

12320-Thread 258 (Thread 0x40ba6940 (LWP 20347)):

12364-#0 0x000000329c40ab99 in pthread_cond_wait@@GLIBC_2.3.2

()

–

69798-#3 0x00002b57b78f56c3 in ObjectSynchronizer::wait ()

69852-#4 0x00002b57b76bd34b in JVM_MonitorWait ()

69897-#5 0x00002aaaab141ece in ?? ()

69929-#6 0×0000000000000000 in ?? ()

69961-Thread 141 (Thread 0x45f27940 (LWP 20532)):

70005-#0 0x000000329c40ab99 in pthread_cond_wait@@GLIBC_2.3.2

()

70065-#1 0x00002b57b7843727 in os::PlatformEvent::park ()

70118-#2 0x00002b57b781c7c2 in Monitor::IWait ()

70162-#3 0x00002b57b781ce2a in Monitor::wait ()

70205-#4 0x00002b57b7977b39 in VMThread::execute ()

70252:#5 0x00002b57b7855c0b in ParallelScavengeHeap::mem_allocate

()

70316:#6 0x00002b57b747873b in

CollectedHeap::common_mem_allocate_noinit ()

70387-#7 0x00002b57b7626ce2 in instanceKlass::allocate_instance

()

70449-#8 0x00002b57b78aa076 in OptoRuntime::new_instance_C ()

70506-#9 0x00002aaaab1948fb in ?? ()

70538-#10 0x00002aaac0741768 in ?? ()

70570-#11 0x00002aaaab761a0c in ?? ()

70602-#12 0x00002aab2dae03c8 in ?? ()

70634-#13 0x00002aaac4035fb0 in ?? ()

70666-#14 0x00002aab2dae2c00 in ?? ()

70698-#15 0x00002aaac0218af0 in ?? ()

70730-#16 0×0000000000000001 in ?? ()

拿到这个堆栈后，猜测是由于该线程在分配一个对象时分配失败，导致触发了Full

GC，于是根据线程ID去找jstack中的信息，很杯具的是由于有时间差，每次都抓不到什么信息。

于是仔细的重新看上面的堆栈，发现在ParallelScavengeHeap::mem_allocate后，进入了VMThread::execute，根据ParallelScavengeHeap的代码：

1

2

3

//

Generate a VM operation

VM_ParallelGCFailedAllocation op(size, is_tlab,

gc_count);

VMThread::execute(&op);

在分配失败时，会通过VMThread来执行failed_mem_allocate，这和堆栈信息也对应上了，于是继续看上面的堆栈信息，最关键的是这几段：

11707-#6 0x00002b57b7886e11 in PSParallelCompact::invoke_no_policy

()

11772-#7 0x00002b57b788d296 in PSScavenge::invoke ()

11820:#8 0x00002b57b7855d7e in

ParallelScavengeHeap::failed_mem_allocate ()

11891-#9 0x00002b57b796b379 in VM_ParallelGCFailedAllocation::doit

()

根据这个堆栈来看，ParallelScavengeHeap::failed_mem_allocate调到了

PSScavenge::invoke()，这个动作是用于执行新生代回收的，但诡异的是这个堆栈上PSScavenge::invoke后，竟然进入了

PSParallelCompact代码，也就是Full GC，这也就说明并不是应用分配了一个巨大的对象，而是正常的Young

GC的触发(其实这个从jstat中就证明了，只是当时太不细心了)，到这一步了，那么关键的问题就是为什么在触发YGC的时候，变成了直接触发Full

GC，从代码上来看如下：

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

bool scavenge_was_done =

PSScavenge::invoke_no_policy();

PSGCAdaptivePolicyCounters* counters =

heap->gc_policy_counters();

if

(UsePerfData)

counters->update_full_follows_scavenge(0);

if

(!scavenge_was_done ||

policy->should_full_GC(heap->old_gen()->free_in_bytes()))

{

if

(UsePerfData)

counters->update_full_follows_scavenge(full_follows_scavenge);

GCCauseSetter

gccs(heap, GCCause::_adaptive_size_policy);

if

(UseParallelOldGC) {

PSParallelCompact::invoke_no_policy(false);

}

else {

PSMarkSweep::invoke_no_policy(false);

}

}

从上面代码来看，只有scavenge_was_done为false或

policy->should_full_GC(heap->old_gen()->free_in_bytes())为true时，

才会触发PSParallelCompact，而从GC日志来看，是没有触发YGC的，于是继续看

PSScavenge::invoke_no_policy代码，从代码来看，只有在下面的代码已经返回的情况下，才会没有任何YGC的日志信息：

1

2

3

4

//

Check for potential problems.

if

(!should_attempt_scavenge()) {

return

false;

}

而should_attempt_scavenge这段代码中最关键的部分如下：

1

2

3

size_t avg_promoted = (size_t)

policy->padded_average_promoted_in_bytes();

size_t promotion_estimate = MIN2(avg_promoted,

young_gen->used_in_bytes());

bool result = promotion_estimate <

old_gen->free_in_bytes();

这也就是常说的GC悲观策略了，也就是说旧生代剩余的空间小于了YGC平均晋升的大小，在GC频繁时，可以看到旧生代剩余还有300多M，觉得这不太可能呀，不过还是决定通过jstat来看看到底怎么样，于是，执行了：

jstat -J-Djstat.showUnsupported=true -snap [pid]

截取部分最重要的信息如下：

sun.gc.generation.1.name=”old”

sun.gc.generation.1.space.0.capacity=1073741824

sun.gc.generation.1.space.0.initCapacity=1073741824

sun.gc.generation.1.space.0.maxCapacity=1073741824

sun.gc.generation.1.space.0.name=”old”

sun.gc.generation.1.space.0.used=744389904

sun.gc.policy.avgBaseFootprint=355284672

sun.gc.policy.avgMajorIntervalTime=9105

sun.gc.policy.avgMajorPauseTime=1640

sun.gc.policy.avgMinorIntervalTime=5171

sun.gc.policy.avgMinorPauseTime=330

sun.gc.policy.avgOldLive=744361216

sun.gc.policy.avgPretenuredPaddedAvg=251

sun.gc.policy.avgPromotedAvg=178848128

sun.gc.policy.avgPromotedDev=106732344

sun.gc.policy.avgPromotedPaddedAvg=499045152

悲观策略检查的其实就是avgPromotedPaddedAvg < space.0.capacity -

space.0.used。

于是原因终于清楚了，由于平均晋升的大小一直 >

旧生代的剩余空间(因为每次FGC后旧生代都只有300多M是空余的，这个在这个应用中是正常的)，导致每次YGC的时候悲观策略一直触发，于是看到的就

是频繁Full GC了，在这个应用中的解决方法比较简单，就是把旧生代放大一点，避免这个现象，例如：-Xms3g -Xmx3g。

可能有同学要关心为什么平均晋升大小会那么大，重启了个别机器，看到刚重启时的gc log如下：

2011-07-17T10:59:03.481+0800: 10.160: [GC [PSYoungGen:

786432K->23851K(917504K)]

786432K->23851K(3014656K), 0.0967130 secs] [Times:

user=0.08 sys=0.03, real=0.09 secs]

2011-07-17T10:59:12.633+0800: 19.312: [GC [PSYoungGen:

810283K->64502K(917504K)]

810283K->64502K(3014656K), 0.0728670 secs] [Times:

user=0.17 sys=0.06, real=0.07 secs]

2011-07-17T10:59:16.286+0800: 22.965: [GC [PSYoungGen:

850934K->131064K(917504K)]

850934K->284737K(3014656K), 0.3072120 secs] [Times:

user=0.91 sys=0.29, real=0.31 secs]

2011-07-17T10:59:19.405+0800: 26.084: [GC [PSYoungGen:

917496K->131047K(917504K)]

1071169K->606647K(3014656K), 0.5184690 secs] [Times:

user=1.73 sys=0.32, real=0.52 secs]

2011-07-17T10:59:21.590+0800: 28.268: [GC [PSYoungGen:

917479K->131048K(917504K)]

1393079K->1019546K(3014656K), 0.5787500 secs]

[Times: user=1.78 sys=0.38, real=0.58 secs]

可以看到，这几次YGC后的平均晋升大小就是：310m+，因此如果此时旧生代只剩300m了，那么就会导致下一次YGC变成FGC，而如果下一次FGC

后旧生代剩余的仍然是300m，那么就开始频繁的FGC了，在这个应用中这个现象比较正常的原因是需要cache一个700多m的东西。

为什么把旧生代空间放大点就能好呢？因为在这个应用中，只是因为刚启动的时候需要加载如此大的cache，所以其实后面随着YGC的进行，这个平均晋升大小会越来越小，另外一个调整了参数的，运行了一天后，平均晋升大小的值为：

sun.gc.policy.avgPromotedPaddedAvg=403000

总结来看，这次排查过程还是绕了很多弯路，其实一开始就应该通过pstack来看，full

gc是什么地方在触发，然后反推就会更快的查出问题了。

从这个Case来看，对于需要Cache比较多内容的场景而言(尤其是启动时既要加载的)，还是要给old留有一定的空间，否则悲观策略就要发威了，:)。

weixin_39885383
关注
系统CPU飙高和频繁GC，我要怎么排查
weixin_43870079的博客
09-04 1111
1. Full GC次数过多 相对来说，这种情况是最容易出现的，尤其是新功能上线时。对于Full GC较多的情况，其主要有如下两个特征： 线上多个线程的CPU都超过了100%，通过jstack命令可以看到这些线程主要是垃圾回收线程 通过jstat命令监控GC情况，可以看到Full GC次数非常多，并且次数在不断增加。 首先我们可以使用top命令查看系统CPU的占用情况，如下是系统CPU较高的一个示...
频繁gc是什么意思_什么情况下会发生full Gc？如何排查频繁发生full Gc的原因？...
weixin_39621235的博客
12-21 2979
GC就是Java的垃圾回收机制，要了解什么情况下会发生GC(即GC得触发条件)，我们需要先了解JVM的内存模型结构，之前一篇文章已经详细讲解了Jvm的内存模型结构，而通常来说，GC主要针对的是堆(java heap)区。而java heap是分代的(年轻代和老年代)，为什么要分代？其实也不难理解，分代就是为了优化性能，如果不分代，那就会导致所有对象揉在一块，那样GC就会对堆区域进行全扫描。所以，分...
频繁gc是什么意思_[JVM]一次线上频繁GC的问题解决
weixin_39830906的博客
12-21 678
起因：周末测试发现线上mq消息积压了十几万的消息，如下图所示每个队列几万的消息，立即采取紧急措施，将队列下线重新上线。处理积压消息的量，调用量起来了，很快消息积压解决了。开始事件复盘。首先分析是否是消息消费能力跟不上消息产生原因，看入口消息，QPS是29.6消息消费QPS如下事后开始分析原因，发现队列积压有如下异常：超时时间设置的很长，大致分析出消息处理线程等待下游接口超时，连接下游接口设置的超时...
频繁gc是什么意思_如何处理频繁创建对象然后丢弃导致频繁GC的情况
weixin_39927408的博客
12-21 491
2011年11月04日 11:51 "@docsun"的内容我觉得设置为null，就可以让GC自动回收了...GC是回收这些内存了，但是GC太频繁。2011-10-28T13:50:45.062+0800: 158.233: [GC 158.233: [DefNew: 237897K->5619K(245760K), 0.0870050 secs] 267424K->48443K(79...
频繁GC问题
kankan_s的专栏
08-03 1942
过大的内存分配会导致GC花费更多的时间来回收内存，过小的内存分配则会导致更频繁的GC触发，以回收短期内不再使用的对象。运行时间过长：如果应用程序运行时间较长，堆中的对象会逐渐增加，GC可能会更频繁地进行，尤其是在垃圾回收器进行Full GC时，会导致长时间的停顿。长时间的请求处理：对于Web应用程序或服务器，如果请求处理时间过长，可能会导致堆内存中的对象积累较多，增加了GC的压力。综上所述，优化GC的频繁发生需要综合考虑应用程序的实际情况和特点，结合合适的调优策略，以提高应用程序的性能和稳定性。
[case9]频繁GC (Allocation Failure)及young gc时间过长分析
weixin_33701251的博客
03-04 2499
序 本文主要分析一个频繁GC (Allocation Failure)及young gc时间过长的case。 症状 gc throughput percent逐步下降，从一般的99.96%逐步下降，跌破99%，进入98%，最低点能到94% young gc time逐步增加，从一般的十几毫秒逐步上升，突破50，再突破100，150，20...
golang GC机制
小二黑嘿嘿的博客
03-09 2266
Golang自1.5版本开始引入三色GC，多次改进，GC停顿时间降低到1ms。 一：GC的触发 GC的触发条件有以下几种： gcTriggerAlways：强制触发GC gcTriggerHeap：当前分配的内存达到一定值就触发GC gcTriggerTime：当一定时间没有执行过GC触发 gcTriggerCycle：要求启动新一轮的GC，已启动则跳过，手动触发GC的runtime.GC()会...
JVM系列4-GC log
唐影若凡的专栏
06-30 4007
1、JVM参数-XX:+PrintGC参数-XX:+PrintGC开启了简单GC日志模式，为每一次新生代（young generation）的GC和每一次的Full GC打印一行信息。日志默认输出到终端。下面举例说明：[GC 1843K->632K(116736K), 0.0112928 secs] [Full GC 632K->558K(116736K), 0.0157125 secs]每行开始首
深入理解JVM(4)——如何优化Java GC
liinux-Talk is cheap,show me the code.
05-02 573
GC优化是必要的吗？ 或者更准确地说，GC优化对Java基础服务来说是必要的吗？答案是否定的，事实上GC优化对Java基础服务来说在有些场合是可以省去的，但前提是这些正在运行的Java系统，必须包含以下参数或行为： 内存大小已经通过-Xms和-Xmx参数指定过 运行在server模式下（使用-server参数） 系统中没有残留超时日志之类的错误日志 换句话说，如果你在运行时没有手动设置内存...
大数据技术之_19_Spark学习_07_Spark 性能调优 + 数据倾斜调优 + 运行资源调优 + 程序开发调优 + Shuffle 调优 + GC 调优 + Spark 企业应用案例
黑泽君
05-04 2043
大数据技术之_19_Spark学习_07_Spark 性能调优 + 数据倾斜调优 + 运行资源调优 + 程序开发调优 + Shuffle 调优 + GC 调优 + Spark 企业应用案例
GC比较频繁
weixin_30750335的博客
01-28 735
GC比较频繁 转载于:https://www.cnblogs.com/fanlinglong/p/10329157.html
又是一个程序员粗心的代码引起频繁FullGC的案例
weixin_33775582的博客
11-08 505
这是笨神JVMPocket群里一位名为"云何*住"的同学提出来的问题，问题现象是CPU飙高并且频繁FullGC。 重现问题 这位同学的业务代码比较复杂，为了简化业务场景，笔者将其代码压缩成如下的代码片段： public class FullGCDemo { private static ScheduledThreadPoolExec...
频繁GC的问题解决
wojiao228925661的博客
06-03 9403
[JVM]一次线上频繁GC的问题解决 起因：周末测试发现线上mq消息积压了十几万的消息，如下图所示 每个队列几万的消息，立即采取紧急措施，将队列下线重新上线。 处理积压消息的量，调用量起来了，很快消息积压解决了。开始事件复盘。 首先分析是否是消息消费能力跟不上消息产生原因，看入口消息，QPS是29.6 消息消费QPS如下 事后开始分析原因，发现队列积压有如下异常： 超时时间设置的很长，大致分析出消息处理线程等待下游接口超时，连接下游接口设置的超时时间很长，为什么下游接.
频繁GC问题原因总结
最新发布
Artisan_w
10-13 1245
此外，合理的内存管理和代码优化也是减少频繁垃圾回收的关键。使用不合理的垃圾回收策略：Java提供了不同的垃圾回收器，每个回收器适用于不同的场景。内存分配过多：如果应用程序频繁地分配新的对象而不释放旧的对象，堆内存将快速用满，触发频繁的垃圾回收。堆内存不足：如果为Java应用程序分配的堆内存不足以容纳应用程序所需的数据，垃圾回收将更频繁地运行，以尝试释放未使用的内存。使用了大量的弱引用或软引用：虽然弱引用和软引用对于某些应用程序非常有用，但过度使用它们可能导致垃圾回收更频繁，因为这些引用的对象更容易被回收。
消除线上GC频繁的“心魔”，提高应用性能！
孤芳不自赏
04-30 998
这篇文章你值得一阅！讲技术我觉得应该让外行也能看明白，而不是一堆专业术语堆砌，像在读天书一般，到最后感觉云里雾里。
JVM频繁GC内存溢出排查
m0_73311735的博客
04-07 1194
以上方式推荐的还是jmap -histo和内存溢出时自动转储，对进程本身影响比较小。另外jmap -heap 可以看堆内存相关的JVM配置和堆内存整体分配。
CPU飙高，频繁GC，怎么排查？
ai_goodStudent的博客
01-15 2362
本文转自 处理过线上问题的同学基本上都会遇到系统突然运行缓慢，CPU 100%，以及Full GC次数过多的问题。当然，这些问题的最终导致的直观现象就是系统运行缓慢，并且有大量的报警。 本文主要针对系统运行缓慢这一问题，提供该问题的排查思路，从而定位出问题的代码点，进而提供解决该问题的思路。 对于线上系统突然产生的运行缓慢问题，如果该问题导致线上系统不可用，那么首先需要做的就是，...
解决jvm GC过于频繁的问题
热门推荐
rogerxue12345的博客
08-07 1万+
JVM配置是这样的： jre1.8， 堆的最大空间是3G，线程执行栈的大小是256K，新生代的大小是1G，老年代的大小是2G.如下图： 结果在日志发现了这个错误： Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded 这个错误产生的原因是，jvm在进行gc的时候, 使用大于98%以上的时间去释放小于2%的heap空间时，才会报这个异常。 这其实是jvm预判将会发生OutOfMemery异常，就提早抛出这个...
系统 CPU 突然飙升且 GC 频繁，如何排查
z_ssyy的博客
12-11 1323
处理过线上问题的同学基本上都会遇到系统突然运行缓慢，CPU 100%，以及Full GC次数过多的问题。当然，这些问题的最终导致的直观现象就是系统运行缓慢，并且有大量的报警。本文主要针对系统运行缓慢这一问题，提供该问题的排查思路，从而定位出问题的代码点，进而提供解决该问题的思路。对于线上系统突然产生的运行缓慢问题，如果该问题导致线上系统不可用，那么首先需要做的就是，导出jstack和内存信息，然后重启系统，尽快保证系统的可用性。
Java full gc 频繁gc 监控gc 什么意思，GC原理，以及GC如何控制
06-07
Java中的GC（垃圾回收）是指自动管理内存的机制，它会自动回收不再使用的内存，以便程序能够获得更多的可用内存。当应用程序需要更多的内存时，Java会自动执行垃圾回收，释放不再使用的内存。 Full GC是指对整个Java堆进行垃圾回收，而非部分回收。频繁GC是指在短时间内多次执行GC操作。监控GC是指对GC的执行进行监控，以便及时发现并解决GC问题。 GC的原理是通过标记和清除的方式来回收不再使用的内存。当Java堆中的对象不再被引用时，GC会标记这些对象为垃圾，然后将其回收。 GC如何控制分为两个方面，一是优化程序代码，减少对象的创建和存储，从而减少GC的发生；二是通过调整JVM的参数，控制GC的执行频率和效率，以适应不同的应用场景。例如，可以通过设置新生代和老年代的大小、调整GC算法、调整GC触发阈值等方式来控制GC的执行。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值