正撸着代码，公司内的聊天工具弹出一条信息： “狼哥，我这个机器总是频繁FGC...” 我赶紧打开对话框，机智的回复一个表情 然后继续默默撸码。 随后，小伙伴砸了一段GC日志过来 2019-09-17T20:33:57.889+0800: 4753520.554: [Full GC (Metadata GC Threshold) 4753520.554: [CMS[YG oc
1.查看监控，了解出现问题的时间点以及当前FGC的频率(可对比正常情况看频率是否正常) 2.了解改时间点之前有无程序上线、基础组件升级等情况 3.了解jvm参数设置，包括:堆空间各个区域大小的设置，新生代和老年代分别采用了什么垃圾收集器，然后分析jvm参数设置是否合理 4.再对步骤1中
1. YGC和FGC说明： YGC ：对新生代堆进行gc。频率比较高，因为大部分对象的存活寿命较短，在新生代里被回收。性能耗费较小。 FGC ：全堆范围的gc。默认堆空间使用到达80%(可调整)的时候会触发fgc。以我们生产环境为例，一般比较少会触发fgc，有时10天或一周左右会有一次。 2. YGC和FGC执行时
1.如果存在大对象或者文件io，适当加大年轻代内存区大小（2G堆内存情况下上传文件频繁fgc，改成4G后解决，或者在2G堆内存时修改默认的年轻代和年老代比值） 2.使用bytebuffer缓冲区 3.直接使用bytebuffer的直接内存区（堆外）https://blog.csdn.net/weixin_39935887/article/details/84957083
Full GC 在设计G1时会极力避免Full GC（以下简称FGC），但是总有一些特殊情况，如果当前并发回收的速度跟不上对象分配的速度，那么需要G1启动后备方案进行FGC。早期G1的FGC使用单线程的标记整理算法，后来为了充分发挥多核处理器的优势，JEP 307提案为G1的FGC设计了多线程标记整理算法，此时
线上服务的GC问题，是Java程序非常典型的一类问题，非常考验工程师排查问题的能力。同时，几乎是面试必考题，但是能真正答好此题的人并不多，要么原理没吃透，要么缺乏实战经验。 过去半年时间里，我们的广告系统出现了多次和GC相关的线上问题，有Full GC过于频繁的，有Young GC耗时过长的，这些问题
阿里妹导读：Java能成为应用最广泛的语言，和他的内存托管机制是分不开的。很多人眼中，Java虚拟机是透明的，只需知道核心api的用法，便可以专注于实现具体业务，然后依赖Java虚拟机运行甚至优化应用。 你是否有过这样的经历，跑得好好的Java进程，突然就瘫痪了。过于依赖Java虚拟机导致
最近线上有一条机器在运行了10几天后出现告警，频繁出现fgc，在切断流量之后，从运维那边拿了应用的heapdump文件。在一开始出现fgc时，我就上了容器平台查看了gc日志，gc日志如下：从日志中可以看出很明显优于metaspace空间不够造成的fgc，而且不断进行fgc，且metaspace空间回收不了。于是查看一下
前言对于后端程序员，特别是 Java 程序员来讲，排查线上问题是不可避免的。各种 CPU 飚高，内存溢出，频繁 GC 等等，这些都是令人头疼的问题。楼主同样也遇到过这些问题，那么，遇到这些问题该如何解决呢？首先，出现问题，肯定要先定位问题所在，然后分析问题原因，再然后解决问题，最后进行总结，防止下次再
