小工匠

文章目录线程Dump日志分析堆Dump可视化分析GC日志分析Alibaba ArthasAliabba jvmGeneratePerfMaPerfMa - XXFox （Java虚拟机参数分析）PerfMa - XSheepdog (Java线程Dump分析)PerfMa - XElephant (Java内存Dump分析)线程Dump日志分析https://fastthread.io在线的 Thread dump分析网站，可以判断 CPU 峰值、死锁、内存异常、应用反应迟钝、响应时间变长和其他

文章目录总结总结第一个是JVM运行我们写好的系统最根本的工作原理，包括：内存各个部分的划分代码在执行的过程中，各个内存区域是如何配合协调工作的对象是如何分配的GC如何触发GC执行的原理是什么常见的用于控制JVM工作行为的一些核心参数都有哪些第二个是对于一个写好的系统，我们应该如何通过预估的方法给他设置一些相对合理的JVM参数，然后在测试的时候如何合理的优化调整JVM的参数另外在线上部署的系统如何对JVM进行监控，如何对线上出现GC性能问题的JVM进行合理的

文章目录背景从现象看到本质通过jstat来确认我们的推断通过MAT找到占用内存最大的对象背景首先说一下案例背景，线上有一个数据同步系统，是专门负责从另外一个系统去同步数据的，简单来说，另外一个系统会不停的发布自己的数据到Kafka中去，然后我们有一个数据同步系统就专门从Kafka里消费数据，接着保存到自己的数据库中去，大概就是这样的一个流程。我们看下图，就是这个系统运行的一个流程。结果就这么一个非常简单的系统，居然时不时就报一个内存溢出的错误，然后就得重启系统，过了一段时间又会再次内存溢出一下。

文章目录背景使用top命令检查机器资源使用在内存使用这么高的情况下会发生什么？底是谁占用了过多的内存？小结背景公司里有一个非常正常的线上的服务，采用的是Web系统部署在Tomcat中的方式来进行启动的。但是有一段时间，我们突然收到一些反馈，说是这个服务非常的不稳定，经常会出现访问这个服务的接口的时候出现服务的假死问题。一旦出现这种接口调用时服务假死的情况，相当于我们的这个服务就完全不可用了，因此收到了不少上游服务的反馈。但是上游服务反馈了另外一个非常关键的情况，就是经常一段时间内无法访问这个服

文章目录PreCase初步分析内存快照功夫在诗外：问题在JVM参数上分析一下JVM的GC日志分析一下JVM运行时内存使用模型优化第一步：增加堆内存大小优化第二步：改写代码总结Pre今天的案例背景是一个每天10亿数据量的日志清洗系统，这个系统做的事情其实非常的简单，他主要就是从Kafka中不停的消费各种日志数据，然后对日志的格式进行很多清洗，比如对一些涉及到用户敏感信息的字段（姓名、手机号、身份证号）进行脱敏处理，然后把清洗后的数据交付给其他的系统去使用。比如推荐系统、广告系统、分析系统都会去使用这

文章目录Pre关于MAT工具对OOM故障的实践意义故障发生现场第一步：检查内存中到底是什么对象太多了Pre这个案例也是我们线上曾经出现过的一个真实的生产案例，是一个年轻的工程师在使用mybatis写SQL语句的时候在某些情况下允许不加where条件就可以执行，结果导致一下子查询出来上百万条数据引发了系统的OOM。这个案例本身是属于比较简单的那种，不涉及太多其他的技术问题，的确就是纯系统代码自身的问题导致的所以我们拿这个案例来给大家再深入讲讲在使用MAT进行线上内存快照分析时候的一些技巧，相信对大

文章目录Pre系统架构介绍故障发生现场初步查找内存溢出的故障发生点分析内存快照找到占用内存最大的对象通过分析源代码找出原因铺垫一个关键知识点：RPC框架的类定义RPC框架的一个bug：过大的默认值！最终的解决方案Pre这个OOM的案例是发生在微服务架构下的一次RPC调用过程中的，也是一次非常奇怪的故障案例解决系统OOM故障的核心能力积累，你必须对你线上系统使用的各种技术，从服务框架，到第三方框架，到Tomcat/Jetty等Web服务器，再到各种底层的中间件系统，对他们的源码最好都要有深入的理解。

使用Jetty作为Web服务器的时候在某个非常罕见的场景下发生的一次堆外内存溢出的场景。

文章目录Pre系统发生OOM的生产现场初步看看Tomcat的底层原理异常日志Review关键的JVM参数对内存快照进行分析低负载的系统为什么处理一个请求需要4秒钟对系统进行优化小结Pre本文将会给大家分析一个线上的真实生产案例，在这个案例中，一个每秒仅仅只有100+请求的系统却频繁的因为OOM而崩溃。在对这个案例进行深度分析的时候，大家会看到一个OOM问题是如何牵扯到Tomcat底层工作原理、Tomcat内核参数的设置、服务请求超时时间等问题的。系统发生OOM的生产现场我们从系统发生OOM的

文章目录PreCode运行用MAT分析内存快照小结Pre上一篇文章已经给大家分析了栈内存溢出是如何来解决的，这篇文章我们给大家分析一下最常见的堆内存溢出是如何来解决的。Code采用的JVM参数如下：-Xms10m-Xmx10m-XX:+PrintGCDetails-Xloggc:gc.log-XX:+HeapDumpOnOutOfMemoryError-XX:HeapDumpPath=./-XX:+UseParNewGC-XX:+UseConcMarkSweep

文章目录Pre栈内存溢出能依托之前的办法解决吗？Code运行代码后分析异常报错信息的调用栈Pre之前的文章，我们分析了Metaspace区域是如何内存溢出的，同时还带着大家分析了一下内存快照。今天这篇文章，我们就带大家分析一下JVM栈内存溢出的时候，怎么来解决。栈内存溢出能依托之前的办法解决吗？首先大家思考一个问题：栈内存溢出能按照之前的方法解决吗？也就是说，GC日志、内存快照，这些东西对解决栈内存溢出有帮助吗？首先明确一点，栈内存溢出跟堆内存是没有关系的，因为他的本质是一个线程的栈中压

文章目录PreCode分析GC日志分析内存快照小结PreMetaspace区域内存溢出 。 我们先分析一下GC日志，然后再让JVM自动dump出来内存快照，最后用MAT来分析一下这份内存快照，从内存快照里去找到内存溢出的原因。Code我们还是用这段代码来说明，但是要记得需要在JVM参数中加入一些东西，因为我们想看一下GC日志和导出内存快照，如下所示：-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:MetaspaceSize=10m-XX:M

文章目录Pre最佳的解决方案一个比较成熟的系统监控体系的建议一种比较Low的JVM OOM问题的被动发现方法系统发生OOM了，应该怎么来处理初步思路自动dump内存快照迄今为止我们可以得出的一份JVM参数模板Pre一旦发生了各种场景下的OOM，我们到底应该如何处理呢？ 所以j继续将会从OOM问题的监控开始，给大家讲OOM的排查、定位和解决的一系列思路最佳的解决方案先给大家说一种最佳的OOM监控方案，其实说白了也很简单， 公司最好是应该有一种监控平台，比如Zabbix、Open-Falcon之类

文章目录Case 1 递归调用Case2 没有缓存的动态代理小结Case 1 递归调用当时有一个非常重要的系统，我们设计了一个链路监控机制，也就是会在一个比较核心的链路节点，写一些重要的日志到Elasticsearch集群里去，事后会基于ELK进行核心链路日志的一些分析，如下图所示。同时我们对这个机制做了规定，如果在某个节点写日志时发生了某些异常，此时也必须将这个链路节点的异常写入ES集群里去，因为我们在分析的时候，需要知道系统运行到这里有一个异常。不知道大家看了上面的代码是作何感想？当

文章目录PreCase针对Kafka故障设计的高可用场景无法释放的内存最终导致OOM故障修复Pre之前我们已经用代码给大家都演示过几种不同的内存溢出的场景了，但是光看代码演示可能大家还是找不到感觉。因此，我们同样也会用曾经遇到过的真实线上系统运行场景来让大家看看是如何触发堆内存溢出的。Case还记得超大数据量的计算引擎系统么？ 之前就用这个系统案例给大家分析过GC问题，但是因为他处理的数据量实在是很大，负载也过高，所以除了GC问题以外，还有OOM问题。首先用最最简化的一张图给大家解释系统的工

文章目录Pre从对象在Eden区分配开始讲起高并发场景下导致ygc后存活对象太多什么时候会发生堆内存的溢出？Case DemoReview 堆内存溢出的一个典型场景模拟Code小结Pre之前的文章已经分析了Metaspace和栈内存两块内存区域发生内存溢出的原理，同时给出了一些较为常见的引发他们内存溢出的场景，一般只要代码上注意一些，不太容易引发那两块区域的内存溢出。重点要来了，真正最容易引发内存溢出的，说白了就是平时我们系统创建出来的对象实在是太多了，最终就导致了系统的内存溢出！从对象在

文章目录Pre一个线程调用多个方法的入栈和出栈每次方法调用的栈桢都是要占用内存的到底什么情况下会导致JVM中的栈内存溢出？一般什么情况下会发生栈内存溢出？Case Demo重新分析一下JVM中的栈内存Review栈内存溢出的原理模拟Code小结Pre上一篇文章我们已经分析了Metaspace区域内存溢出的原理和两种情况，这篇文章我们就顺着JVM的运行原理继续分析一下，线程的栈内存是如何内存溢出的。因为在JVM加载了我们写的类到内存里之后，下一步就是去通过线程执行方法，此时就会有方法的入栈出栈相关的

文章目录PreMetaspace区域是如何触发内存溢出的？到底什么情况下会发生Metaspace内存溢出？Metaspace OOM 模拟CGLIB动态生成类的代码示例限制Metaspace大小看看内存溢出效果小结Pre上一篇文章我们已经把JVM的运行原理重新回顾了一遍，大家脑子里应该能重新浮现出JVM运行我们写的那些代码的流程图了。而且结合那个运行流程，我们也点出来了有哪几块区域可能会发生内存溢出，那么今天我们就来着重分析一下Metaspace区域到底为什么会发生内存溢出。Metaspace

文章目录OOMOOM是如何产生的JVM进程怎么执行你写的那些代码Java虚拟机栈：让线程执行各种方法堆内存：放我们创建的各种对象小结OOM先不考虑自己系统外部依赖的缓存、消息队列、数据库等等东西挂掉，就我们自己系统本身而言，最常见的挂掉的原因是什么？其实就是系统OOM，也就是所谓的内存溢出！其实说白了，也非常非常的简单，一句话形容，你的JVM内存就这么点，结果你拼命的往里面塞东西，结果内存塞不下了，不就直接溢出了吗？看看下面的这个图至于到底JVM是如何放不下对象导致内存溢出的，这个大家不要着

文章目录新系统开发完毕之后如何设置JVM参数？在压测之后合理调整JVM参数线上系统的监控和优化线上频繁Full GC的几种表现频繁Full GC的几种常见原因一个统一的JVM参数模板新系统开发完毕之后如何设置JVM参数？之前花费了很多的精力给大家介绍，在一个新系统开发完毕之后，到底该如何预估性的合理设置JVM参数？毕竟直接用默认的JVM参数部署上线再观察，是非常的不靠谱的。很多公司也没有所谓的JVM参数模板。首先大家应该估算一下自己负责的系统每个核心接口每秒多少次请求，每次请求会创建多少个对象，

文章目录PreJVM和GC的运行原理Pre我们已经把完整的JVM运行原理、GC原理以及GC优化的原理，还有线上发生GC问题的各种优化案例分析完了，所以到这里务必停一停脚步，整理一下学习过的知识脉络 。JVM和GC的运行原理对于JVM的学习，首先务必要搞清楚一点，JVM是如何运行起来的。JVM的内存区域划分，最核心的就是这么几块了：年轻代、老年代、Metaspace（也就是以前的永久代）。其中年轻代又分成了Eden和2个Survivor，默认比例是8：1：1，如下图。接着我们来思考一下，

文章目录案例CPU负载高原因分析Full GC频繁的原因分析案例升级过后才半小时， 系统对应的前端页面无法访问了，所有用户全部看到的是一片空白和错误信息。这个时候通过监控报警平台也收到大量报警，发现线上系统所在机器的CPU负载非常高，持续走高，甚至直接导致机器都宕机了。所以系统对应的前端页面当然是什么都看不到了。CPU负载高原因分析上篇文章已经给大家总结过CPU负载高的原因了，这里我们直接说结论，看了一下监控和jstat，发现Full GC非常频繁，基本上两分钟就会执行一次Full GC，而

文章目录案例初步排查CPU负载过高的原因初步排查频繁Full GC的问题对线上系统导出一份内存快照MAT是如何使用基于MAT来进行内存泄漏分析案例先简单说一下业务背景：一次我们线上推了一个大促销活动, 系统一般在这个时候压力会比平时大好几倍。但是因为从系统的整体设计角度而言，其实给的一些数据库、缓存和机器的资源都是足够的，所以通常而言不该有什么问题。但是那次大促活动开始之后，直接导致线上一个系统的CPU使用率飙升，而且因为CPU使用率太高，导致系统几乎陷入卡死的状态，无法处理任何请求！在重启系

文章目录案例Why解决办法案例案例是这样，有一次一个新系统上线，平时都还算正常，结果有一次大促活动的时候，这个系统就直接卡死不动了大家注意，是直接卡死不动！也就是说，所有请求到这个系统就直接卡住无法处理，无论如何重启这个系统都没任何效果。这个时候我们当然会想，是不是按照之前的思路，一点一点去分析JVM的GC问题，考虑是不是过于频繁的GC问题导致了系统被卡死？那当然是会按照之前的思路去分析的，首先使用jstat去看一下系统运行情况，令人吃惊的事情是：JVM几乎每秒都执行一次Full GC，每次都

文章目录业务背景未优化前的JVM性能分析未优化前的线上JVM参数根据线上系统的GC情况倒推运行内存模型老年代里到底为什么会有那么多的对象？定位系统的大对象针对本案例的JVM和代码优化思考业务背景今天的这个案例也是我们之前线上系统经历过的一个真实的生产JVM优化案例，这个优化的过程比较复杂，经过了多次优化，当然核心原理和知识其实还是之前给大家讲解过的那些东西。只不过这个真实生产系统优化的过程大家如果能理解透彻，那么对于大家利用学过的知识和掌握的工具自己去进行JVM优化的时候，肯定是大有好处的。这个

文章目录Pre问题的产生查看GC日志查看Metaspace内存占用情况一个综合性的分析思路Pre本文会给大家讲解一个比较特殊的JVM优化案例，这个优化案例本身是因为新手工程师对JVM优化可能了解了一个半吊子，然后不知道从哪里找来了一个非常特殊的JVM参数错误的设置了一下，就导致线上系统频繁的出现Full GC的问题。但是我们后续大量的优化案例其实都是各种各样奇形怪状的场景，因为正是各种奇怪场景才能让大家逐步积累出来较为丰富的JVM优化实战经验了解的场景越多，自己未来在处理JVM性能问题的时候才能

文章目录业务背景JVM性能问题如何优化每次Full GC的性能？调优后的效果思考业务背景这个JVM性能优化的案例，很多核心的思想其实也跟之前是相同的，只不过在优化的过程中会带出来一些比较高级的参数的调优。业务背景，这是一个垂直电商公司,一些细分领域的电商业务.注册用户量有就数百万的规模，每日活跃用户数量几十万，每天APP的整体请求量也就小几千万的级别，也并不大。高峰期的QPS也就每秒数百请求但即使如此的一个普通APP的后台系统，感觉上压力一点儿都不大，是不是真的就没有JVM的性能问题呢？当然

文章目录Pre案例背景高并发查询导致对象快速进入老年代老年代必然会触发频繁GC优化前的线上系统JVM参数频繁Full GC导致的大量内存碎片如何进行优化？思考题Pre这篇文章开始，我们会开始用一系列真实的生产案例给大家还原出来各种各样不同的JVM优化场景力求让大家在不同的业务背景下，对不同的原因产生的JVM性能问题进行分析和处理，进而积累出来大量不同场景下的JVM性能优化经验。所有的JVM优化案例都是基于之前几十篇文章教给大家的核心原理以及优化手段来展开的，因此大家可以认为，之前几十篇文章学习完

文章目录Pre运行程序用的示例JVM参数CodePrejvm性能调优实战 - 27亿级数据量的实时分析引擎，为啥频繁发生Full GC分析了一个实时计算系统因为负载过高导致了非常频繁的Full GC这里先在下面贴出来之前的内容，大家先看一下回顾回顾，接着我们会给出示例代码，运行起来之后通过jstat来观察其运行中的问题。然后我还会优化一下JVM参数配置，再次运行系统，通过jstat来观察JVM优化以后的效果。运行程序用的示例JVM参数下面的参数唯一修改的就是“-XX:PretenureS

文章目录Pre模拟代码的JVM参数设置示例Code如何在windows上执行命令？通过jstat观察程序的运行状态Prejvm性能调优实战 - 26一个每秒10万并发的系统如何频繁发生Young GC的之前我们给大家分析过的一个案例，就是一个BI系统因为负载很高所以触发了非常频繁的Young GC ，再来回顾一遍这个案例回顾之后，我们接着用代码模拟出这个案例的场景，然后用jstat来分析一下jvm的运行状态，带大家来实战一下jstat命令的使用。模拟代码的JVM参数设置接着我们会用一段程序

文章目录Pre开发好系统之后的预估性优化系统压测时的JVM优化对线上系统进行JVM监控Pre前面两篇文章，已经给大家介绍了jstat、jmap、jhat等工具，可以非常轻松的分析出系统运行时的JVM状况，包括内存使用压力还有GC压力，包括内存中的对象分布情况。这篇文章，我们结合之前介绍过的两个工具，给大家做一个实际开发、测试到上线的一个整体JVM优化的梳理。开发好系统之后的预估性优化平时如果在开发一个新系统的时候，完成开发之后，是不是就要经历测试以及上线的过程？此时在系统开发完毕之后，实际

文章目录Pre使用jmap了解系统运行时的内存区域jmap -heap PID使用jmap了解系统运行时的对象分布jmap -histo PIDPre上一篇文章我们给大家介绍了一个平时工作中非常实用的工具，jstat。用jstat就可以非常轻松便捷的了解到线上系统的运行状况，从新对象增速、Young GC触发频率以及耗时，再到对象进入老年代的增速以及Full GC触发频率以及耗时，可以完全摸清楚线上系统的JVM运行情况，为可能要做的优化做准备。本文我们继续给大家介绍两个平时工作里非常实用的工具，

文章目录Pre功能强大的jstatjstat -gc PID其他的jstat命令如何使用jstat工具？新生代对象增长的速率Young GC的触发频率和每次耗时每次Young GC后有多少对象是存活和进入老年代Full GC的触发时机和耗时总结思考题Pre之前已经通过带着大家分析GC日志的方式，给大家重新回顾了一遍JVM的整体运行原理，包括对象优先在Eden区分配，Young GC的触发时机和执行过程，对象进入老年代的时机，Full GC的触发时机和执行过程，相信大家通过GC日志可以把JVM整体运行

文章目录PreCodeJVM 参数GC日志日志分析思考题Pre前两篇文章已经给大家分析清楚了对象是如何进入老年代的，接着我们就给大家演示一下，老年代的GC是如何触发的。CodeJVM 参数“-XX:NewSize=10485760 -XX:MaxNewSize=10485760 -XX:InitialHeapSize=20971520 -XX:MaxHeapSize=20971520 -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 -X

文章目录Pre新生代多久会塞满触发Minor GC的时候会有多少对象进入老年代？系统运行多久，老年代大概就会填满？系统运行多久，老年代会触发1次Full GC？该案例应该如何进行JVM优化？如果该系统的工作负载再次扩大10倍呢？使用大内存机器来优化上述场景总结思考Pre这个案例将会给大家分析一个频繁Full GC的真实生产案例，我们会延续之前讲过的一个案例，继续进行分析，下面先把之前的案例贴出来放在下文。先给大家说一下这个系统的案例背景，大概来说是一个数据计算系统，日处理数据量在上亿的规模。为了

文章目录业务简介系统初期技术痛点：实时自动刷新报表 + 大数据量报表没什么大影响的频繁Young GC提升机器配置：运用大内存机器用G1来优化大内存机器的Young GC性能小结思考业务简介一个服务于百万级商家的BI系统。简单来说，比如你是一个平台，然后有数十万甚至上百万的商家在你的平台上做生意，会使用你的这个平台系统此时一定会产生大量的数据，然后基于这些数据我们需要为商家提供一些数据报表，比如：每个商家每天有多少访客？有多少交易？付费转化率是多少？当然实际情况会比这个简单几句话复杂很多，我们

文章目录PreCodeGC日志GC日志分析Pre上篇文章给大家分析了一下对象是如何通过动态年龄判定规则进入老年代的，同时让大家自己动手去模拟写代码体验一下对象达到15岁之后自动进入老年代的场景。今天这篇文章我们就来给大家示范一下，对象是如何在Young GC过后因为放入下Survivor区域，就直接进入老年代了。CodeGC日志然后我们使用之前的JVM参数来跑一下上面的程序，可以看到下面的GC日志：0.421: [GC (Allocation Failure) 0.421: [ParN

文章目录Pre动态年龄判定规则Pre上一篇文章我们已经带着大家初步分析了一次Young GC的日志，相信大家已经完全掌握了如何结合GC日志去分析一次Young GC执行的全过程。这篇文章我们接着之前的案例继续来做实验，动手体验一下对象是如何从新生代进入老年代的。动态年龄判定规则之前我们给大家总结过对象进入老年代的4个常见的时机：躲过15次gc，达到15岁高龄之后进入老年代；动态年龄判定规则，如果Survivor区域内年龄1+年龄2+年龄3+年龄n的对象总和大于Survivor区的

文章目录PreJVM参数示范GC日志配置Code分析对象是如何分配在Eden区内的采用指定JVM参数运行程序Pre之前的文章大部分都是在分析JVM的运行原理、GC原理以及优化原理，从这里开始我们将要通过各种代码模拟出来JVM的各种场景，同时结合GC日志去分析到底JVM是怎么运行的。今天的文章，我们将会给大家通过代码演示年轻代的Young GC是如何发生的，同时告诉大家如何在JVM参数中去配置打印对应的GC日志，然后我们通过GC日志来慢慢的分析JVM的GC到底是如何运行的。JVM参数示范首先，

前面二十几篇分析了JVM的核心运行原理，还有JVM GC的工作原理 同时，结合案例分析了JVM什么情况下会出现GC的问题，平时我们说优化JVM，到底是在说优化JVM的什么东西 。 这里我们来总结一下