对Apache HttpClient 使用不当导致的内存溢出进行详细的分析，原理探讨、压测验证和修复。

前几天排查了一个业务接口执行高延迟的问题，也挺有参考意义的，分享一下排查过程。 现象是业务反馈有一个接口业务逻辑其实很简单，但是调用一次耗时，如下图所示： 排查应用运行状态 首先第一步需要查看当时的应

一、背景 没想到24年上半年经历了两次域内服务G1的GC问题，上次是Mixed GC。这次是业务服务BizService，它承担了子域内几乎所有的业务能力，场景主要为吸纳增量用户，所以注定不会承担极高

奇怪现象 你是否遇到过服务内部即使设置了线程超时时间，上游依旧报超时异常？ 你是否遇到过下游服务快速响应，当前服务后续方法无耗时逻辑。但偏偏整体执行耗时极长？ 你是否遇到过gc耗时规律性增长？却与流量

分代ZGC是ZGC的一个实现版本，依据假说：应用中大部分对象都是短生命周期的，被设计为分代。它是一个可伸缩的低延迟垃圾收集器，最高支持TB级堆内存，能并发执行繁重任务，且不会让应用的暂停时间超过1ms

线上又有服务CPU爆高了呀，分析一下原因，是JVM频繁垃圾回收导致，dump下内存文件看看，下面说下如何使用Jprofiler进行内存分析。

垃圾收集器日志文件可以帮助定位代码中的问题，并确定服务器或虚拟环境的正确尺寸。 确定运行 Java 应用程序的 理想内存大小 可能非常困难。但随着云实例成本和生态影响的不断上升，正确地调整机器尺寸以处

使用 jpackage 打包发布；使用 jlink 构建 runtime，制作 bat（或 exe）启动脚本；利用 exe4j 制作 exe；手工精简 JRE 构建 runtime

此时就非常推荐SkyWalking了，SkyWalking不仅仅是一款链路跟踪工具，还可以作为一个系统监控工具，还具有告警功能。使用简便、上手又快。真可谓快、准、狠。