mxt51220的博客

本篇介绍了JVM中垃圾回收器相关的基础知识，后续会深入介绍CMS、G1、ZGC等不同垃圾收集器的运作流程和原理，欢迎关注。

大家都是有经验的Java开发人员，想想为何要学习JVM?[面试?调优?装逼?不管出于何种原因，总之你得先学好。那怎么学好呢?每个人对于JVM的了解可能不一样，这就要考虑到怎么切入既然大家都学习过Java，那不妨就从Java开始聊起，同时也是扫盲，毕竟不是每个小伙伴都是计算机专业。

Synchronized，Java 友好的提供了的一个关键字，它让开发者可以快速的实现同步。它就像一个星星，远远看去就是一个小小的点。但是走近一看，却是一个庞大的蛋糕。而这篇文章就是要将这个巨大的蛋糕切开，吃进肚子里面去。

最近，我们系统配置了GC耗时的监控，但配置上之后，系统会偶尔出现GC耗时大于1s的报警，排查花了一些力气，故在这里分享下。当我在jdk的bug库中搜索问题时，发现不少和G1大对象相关的优化，早期JDK(如JDK8)的G1实现可能在大对象回收上不太完善，所以写代码时要注意尽量少创建大对象，以回避这些隐性问题。注：这之后又遇到了耗时高，竟也和大对象有关，添加后解决，看来大对象是万恶之源啊😂。

我们手动调用多少次不影响JVM的行为 若JVM检测到finalized状态的对象变成unreachable，回收其内存(I)，若对象并未覆盖finalize方法，JVM会进行优化，直接回收对象（O）执行finalize方法完毕后，GC会再次判断该对象是否可达，若不可达，则进行回收，否则，对象“复活”。大致描述一下finalize的运行流程：当对象变成(GC Roots)不可达时，GC会判断该对象是否覆盖了finalize方法，若未覆盖，则直接将其回收。

前段时间一位读者面了阿里，在二面中被问到 GC 日志分析，感觉回答的不是很好，过来找我复盘，大致听了他的回答，虽然回答出了部分，但是没抓到重点。GC 日志分析算是 JVM 调优中比较难的部分，今天这篇文章就来聊聊如何利用 JDK 现有的命令并且借助可视化工具如何去分析 GC 日志。

流程图整个内存分配的流程如上图所示。MCC扫包的默认配置是扫描所有的JAR包。在扫描包的时候，Spring Boot不会主动去释放堆外内存，导致在扫描阶段，堆外内存占用量一直持续飙升。当发生GC的时候，Spring Boot依赖于finalize机制去释放了堆外内存；但是glibc为了性能考虑，并没有真正把内存归返到操作系统，而是留下来放入内存池了，导致应用层以为发生了“内存泄漏”。所以修改MCC的配置路径为特定的JAR包，问题解决。笔者在发表这篇文章时，

诚然，作为Java开发人员，我们每一个人都需要拥有Java程序性能的优化方法、思想以及技巧。在这基础上如果可以深入地剖析和学习JDK的实现那肯定就更好了！本篇文章分享的这份Java程序性能优化的笔记就是带大家深入剖析了软件设计层面、代码层面和JVM虚拟机层面的优化方法。

由于现在大多计算机都是多核CPU，多线程往往会比单线程更快，更能够提高并发，但提高并发并不意味着启动更多的线程来执行。更多的线程意味着线程创建销毁开销加大、上下文非常频繁，你的程序反而不能支持更高的TPS。