使用Java语言开发应用程序，虽然JVM帮我们进行了GC收集、清除工作；但是使用不当的话，还是会导致某些对象常驻堆空间无法给垃圾收集器清除，导致内存泄露、内存溢出等情况，今天盘点一下在项目中进行内存泄露分析和GC分析的一些常用、好用的工具。
随着系统自身数据量的增长，访问量增加，系统的响应通常会越来越慢，或者是新的功能在性能上无法满足修去，这个时候需要对系统进行性能调优。调优是一个复杂的过程，涉及的方面有：硬件，操作系统，运行环境软件和应用本身。
在高并发下，Java程序的GC问题属于很典型的一类问题，带来的影响往往会被进一步放大。不管是「GC频率过快」还是「GC耗时太长」，由于GC期间都存在Stop The World问题，因此很容易导致服务超时，引发性能问题。
lsof -i -P | grep LISTEN |grep java 查看应用端口
在 Linux 上遇到性能问题时，可使用 perfcollect 收集跟踪，以便收集有关出现性能问题时计算机上发生的状况的详细信息。
Java中，引用和对象是有关联的。如果要操作对象则必须引用进行。因此，简单的办法是通过引用计数来判断一个对象是否可以回收。简单的说，给对象中添加一个引用计数，每当有一个引用失效时，计数器值减1，任何时刻计数器值为0的对象就是不可能再被利用的，那么这个对象就是可回收对象。那么为什么主流的Java虚拟机里面都没有选择这种算法呢？主要的原因是它很难解决对象之间相互循环引用的问题。
目前采用微服务架构已经逐渐成为企业架构的标准范式，而大多微服务是基于Spring Cloud框架来进行应用的构建的，所以在开发实践中，甚至生产环境中，会遇到java相关问题，例如系统运行变慢、内存OOM，堆栈异常等问题，这里结合我之前的一些实践提供一些相关工具，和大家一起分享我们的诊断思路和解决技巧。
类似Linux的ps,但是jps只用于列出Java的进程 可以方便查看Java进程的启动类,传入参数和JVM参数等 直接运行,不加参数,列出Java程序的进程ID以及Main函数等名称
若要安装最新版 dotnet-gcdump NuGet 包，请使用 dotnet tool install 命令：
jstat用法 其中-gc可以换成-class 、-gcnew、-gcold等参数；而54992表示的JVM的进程id（可能通过上面的jps命令查看） ;4s表求每4秒打印一次，后面的3表求共打印三次。 打印的各参数含义如下： 1：S0C、S1C、S0U、S1U：Survivor 0/1区容量（Capacity）和使用量（Used） 2：EC、EU：Eden区容量和使用量 3：OC、OU：年老代容量和使用量 4：MC、MU：元数据区容量和使用量 5：CCSC、CCSU：压缩类空间容量和使用量 5：YGC、YGT：年轻代GC次数和GC耗时 6：FGC、FGCT：Full GC次数和Full GC耗时 7：GCT：GC总耗时 jstat可以用来判断系统是否出现了内存泄漏，方法是通过一短长时间的观察OU的增长情况，如果OU稳定增长，则有可能出现内存泄漏。
在实际的故障排查、性能监控中，常常是操作系统的工具和Java虚拟机的工具结合使用。
StackOverflowError 与 OutOfMemoryError 是两个老生常谈的 Java 错误。Java 中的虚拟机错误 VirtualMachineError 包括以下四种：
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。从表面上，物理内存应该
JVM本质就是一个进程，因此其内存空间（也称之为运行时数据区，注意与JMM的区别）也有进程的一般特点。深入浅出 Java 中 JVM 内存管理，这篇参考下。
ZGC 启用Large Pages 是一种对应用高性能的折中（吞吐量、低延迟及启动时间），但是却不会带来明显的弊端。除了在应用启动上需要稍微复杂的配置，所需要的系统相关root权限需要手动进行配置。
如果你的Linux服务器突然负载暴增，告警短信快发爆你的手机，如何在最短时间内找出Linux性能问题所在？
JDK 提供了一系列用于监控、诊断 Java 进程的工具，它们在 JDK 安装目录的 bin 目录下，有 jps、jcmd、jstack、jinfo、jmap 等。其中jmc、jconsole、jvisualvm 是 GUI 工具，其他大部分都是命令行工具。
CMS（标记-清除）——》G1（标记整理）——》ZGC（染色指针，多重映射等技术）
1.1 jps 类似Linux的ps,但是jps只用于列出Java的进程 可以方便查看Java进程的启动类,传入参数和JVM参数等 直接运行,不加参数,列出Java程序的进程ID以及Main函数等
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。
CPU诊断主要关注平均负载(Load Average), CPU使用率，上下文切换(Context Switch), 常用的top命令查看cpu使用率以及服务器负载情况。
我们日常接触性能诊断问题，一般分为两种情况，一是线上应用真的出现性能问题；二是我们需要对准备上线的系统进行性能预估；后者需要压力测试辅助进行，此处不表。
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。从表面上，物理内存应该是足够使用的；但实际运行的情况是，会发生大量使用SWAP(说明物理内存不够使用 了)，如下图所示。由于SWAP和GC同时发生会致使JVM严重卡顿，所以我们要追问：内存究竟去哪儿了？
在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约 600m，Linux自身使用大约800m。从表面上，物理内存应该是足够使用的;但实际运行的情况是，会发生大量使用SWAP(说明物理内存不够使用 了)，如下图所示。同时，由于SWAP和GC同时发生会致使JVM严重卡顿，所以我们要追问：内存究竟去哪儿了要分析这个问题，理解JVM和操作系统之间的内存关系非常重要。接下来主要就Linux与JVM之间的内存关系进行一些分析。 一、Li
引言 在一些物理内存为8g的服务器上，主要运行一个Java服务，系统内存分配如下：Java服务的JVM堆大小设置为6g，一个监控进程占用大约600m，Linux自身使用大约800m。从表面上，物理内存
Java 应用性能优化是一个老生常谈的话题，典型的性能问题如页面响应慢、接口超时，服务器负载高、并发数低，数据库频繁死锁等。尤其是在“糙快猛”的互联网开发模式大行其道的今天，随着系统访问量的日益增加和代码的臃肿，各种性能问题开始纷至沓来。
类似Linux的ps，但jps只列出Java进程。可方便查看Java进程的启动类、传入参数和JVM参数。直接运行，不加参数，列出Java程序的进程ID及Main函数名称。
JMeter是一款压力、接口等等的测试工具，Jmeter也可以像loadrunner一样监控服务器CPU、内存等性能参数，用来监控服务器资源使用情况，不过需要安装一些插件。JMeter正常自带可以通过Tomcat的/manager/status来监控服务资源使用情况。这种情况只能监控Tomcat支持的资源使用部分。 通过本文宏哥主要来说一下如何通过JMeter插件来监控服务器CPU、内存（Memory）、磁盘（DisKs I/O）、网络（NetWork I/O）等相关资源。
我发现很多人没办法高效地解决问题的关键原因是不熟悉工具，不熟悉工具也还罢了，甚至还不知道怎么去找工具，这个问题就大条了。我想列下我能想到的一个Java程序员会用到的常用工具。 一、编码工具 1.IDE：Eclipse或者IDEA，熟悉尽可能多的快捷键，《Eclipse常见快捷键列表》 2.插件： (1) Findbugs，在release之前进行一次静态代码检查是必须的 (2) Clover，关心你的单元测试覆盖率 (3) Checkstyle 代码风格检查 3.构建和部署工具:ant或者maven，现在主流都是maven了吧，使用nexus搭建maven私服，再加上持续集成jenkins。代码质量不用愁。 4.版本管理工具： svn或者git 5.diff和patch 6.设置你的eclipse或者IDEA，如formatter,save actions以及code template等。代码风格，直接用google的也可以啊。《Google style guide》 7.掌握一个文本编辑器，Emacs或者VIM，熟悉常用快捷键。这在你需要在线编辑代码，或者编写其他语言代码时候特别有用。《神器圣战》 二、JDK相关 1.jstat : 观察GC情况，如：
类似Linux的ps，但jps只列出Java的进程。可方便查看Java进程的启动类、传入参数和JVM参数。直接运行，不加参数，列出Java程序的进程ID及Main函数名称。
Java 应用性能优化是一个老生常谈的话题，典型的性能问题如页面响应慢、接口超时，服务器负载高、并发数低，数据库频繁死锁等。 尤其是在“糙快猛”的互联网开发模式大行其道的今天，随着系统访问量的日益增加和代码的臃肿，各种性能问题开始纷至沓来。 Java 应用性能的瓶颈点非常多，比如磁盘、内存、网络 I/O 等系统因素，Java 应用代码，JVM GC，数据库，缓存等。
前面介绍了JVM相关的内存和线程相关的技术。对于JVM也算有了一个比较系统、完整的理论基础。理论总是作为指导实践的工具，但是从理论到实践，总会遇到一些虚拟机相关问题，故障。所以还需要学习一些常用的JVM排障工具，和一些常见的调优手段。
看一段线上的gc日志，这是一段CMS完整步骤的日志，对于GC日志格式，不了解的可以再温习一下《GC及JVM参数》
1、在Linux中启动项目：java -cp ref-jvm.jar -XX:+PrintGC -Xms200M -Xmx200M ex13.FullGCProblem
Java常见线上问题总结绝⼤多数Java线上问题从表象来看通常可以归纳为4个方面：CPU、内存、磁盘、网络。比如，应用上线后突然CPU使用率99%、内存泄漏、STW时间过长，这些问题通常可以分为两大类：系统异常 （CPU占用率过高、磁盘使用率100%、系统可用内存低等）业务异常 （服务运⾏⼀段时间⾃动退出、服务间调⽤时间过⻓、多线程并发异常、死锁等）1.如何去定位问题解决问题的第⼀步是定位问题，排查手段⼀般包括以下⼏项，也可以将此理解为排查顺序：业务⽇志分析排查APM分析排查物理环境排查应⽤服务排查云⼚商或
之前线上有过一两次OOM的问题，但是每次定位问题都有点手足无措的感觉，刚好利用星期天，以测试环境为模版来学习一下Linux常用的几个排查问题的命令。 也可以帮助自己在以后的工作中快速的排查线上问题。
CPU 过高、Full GC次数过多、内存使用过多、硬盘空间不足等问题，都会带来系统突然运行缓慢的问题，也是面试特别容易被问到的，下面针对系统运行缓慢等问题进行展开。
不同的 GC 堆大小动态伸缩有很大很大的差异（比如 ParallelGC 涉及 UseAdaptiveSizePolicy 启用的动态堆大小策略以及相关的 UsePSAdaptiveSurvivorSizePolicy、UseAdaptiveGenerationSizePolicyAtMinorCollection 等等等等的参数参与决定计算最新堆大小的方式以及时机），在这个系列以后的章节我们详细分析每个 GC 的时候再详细分析这些不同 GC 的动态伸缩策略。我们这里仅涉及大多数 GC 通用的堆大小伸缩涉及的参数：MinHeapFreeRatio 与 MaxHeapFreeRatio：
该命令主要与jmap搭配使用，用来分析jmap转储的转储快照。其中构建了一个微型的http/html服务器。生成dump文件的分析结果后可以通过浏览器进行查看。 通常情况下不采用jhat进行分析，一方面，分析工作需要耗费额外的资源和时间，既然都要在其他机器进行，则不需要限定于上述工具。另外一方面，jhat界面比较简陋，可以用visualVM，eclipse的Memory Analizer 等更加专业的分析工具进行替换。
Java 应用性能优化是一个老生常谈的话题，典型的性能问题如页面响应慢、接口超时，服务器负载高、并发数低，数据库频繁死锁等。尤其是在“糙快猛”的互联网开发模式大行其道的今天，随着系统访问量的日益增加和代码的臃肿，各种性能问题开始纷至沓来。Java 应用性能的瓶颈点非常多，比如磁盘、内存、网络 I/O 等系统因素，Java 应用代码，JVM GC，数据库，缓存等。笔者根据个人经验，将 Java 性能优化分为 4 个层级：应用层、数据库层、框架层、JVM 层，如图 1 所示。
一般是频繁递归创建方法造成的(每次调用都要在栈里面压一大堆乱七八糟的东西，比如说返回地址，比如说参数，还可能有执行上下文等等。):
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
云直播
对象存储
