继 [【RocketMq】NameServ启动脚本分析（Ver4.9.4）] 之后又来看看Broker的脚本。总体上来看大差不差，以阅读核心的配置部分调优为主。
要说理解JVM的垃圾回收，什么引用计数，Copy GC，mark & compaction好像都不是必须要掌握的东西。真要说对普通的Java程序员比较重要的东西，我觉得必须得有分代式垃圾回收。 jst
jmap -dump:format=b, file=20200208.dump 3806
前言 对于JVM的性能监控，主要注意以下关键参数，通过jdk自带的命令行工具，即可查看相关参数，从而分析系统或目标服务程序中存在的性能瓶颈 jps JVM Process Status Tool的缩写，JVM进程状况工具。 主要功能： 列出正在运行的java进程，并显示执行主类的名称及进程在本地JVM中的ID。 与ps命令相似，可以查看java进程ID(LVMID)。 使用方法： jps [options][hostid] [options]:-q: 只输出LVMID -m: 输出JVM启动时传给主类的方
前面的博文我们介绍了一些关于jvm的一些基础知识，本文介绍一些jdk的命令行工具，通过这些工具我们可以对运行日志、异常堆栈、GC日志、线程快照(threaddump/javacore 文件)、堆转储快照（heapdump/hprof 文件)等文件进行分析，从而定位解决问题。 jdk的彬目录中有许多命令行工具，其中java.exe、javac.exe这两个命令行工具是我们最熟悉的。同时，还有其他的许多命令行工具，我们今天介绍的就是这些命令行工具中的一部分。bin目录内容如下图所示。
在开发的过程中,可以通过oracle的jdk,bin目录下的jvisualvm.exe查看是否死应用锁,且会发现有线程一直在休眠状态
Java GC就是JVM记录仪，书画了JVM各个分区的表演。 什么是 Java GC Java GC（Garbage Collection，垃圾收集，垃圾回收）机制，是Java与C++/C的主要区别之一，作为Java开发者，一般不需要专门编写内存回收和垃圾清理代码，对内存泄露和溢出的问题，也不需要像C程序员那样战战兢兢。这是因为在Java虚拟机中，存在自动内存管理和垃圾清扫机制。概括地说，该机制对JVM（Java Virtual Machine）中的内存进行标记，并确定哪些内存需要回收，根据一定的回收策略，
大家都知道，jvm在启动的时候，会执行默认的一些参数。一般情况下，这些设置的默认参数应对一些平常的项目也够用了。但是如果项目特别大了，需要增加一下堆内存的大小、或者是系统老是莫明的挂掉，想查看下gc日志来排查一下错误的原因，都需要咱们手动设置这些参数。
使用 javap 可以查看 Java 字节码反编译的源文件，javap 的命令格式如下：
武培轩(公众号：武培轩)的《不可不知的7个JDK命令》这篇文章，短小精悍，介绍的这7个JDK命令非常实用，值得借鉴。
所谓的标准参数，就是不会随着我们JDK 变化而变化版本的参数 这种参数可以通过Java -help查看（和Java -version使用方式一样）
jvm 调优，调的是稳定，并不能带给你性能的大幅提升。服务稳定的重要性就不用多说了， 保证服务的稳定，gc 永远会是 Java 程序员需要考虑的不稳定因素之一。复杂和高并发下的 服务，必须保证每次 gc 不会出现性能下降，各种性能指标不会出现波动，gc 回收规律而且干净，找到合适的 jvm 设置。Full gc 最会影响性能，根据代码问题，避免 full gc 频率。可以 适当调大年轻代容量，让大对象可以在年轻代触发 yong gc，调整大对象在年轻代的回收频 次，尽可能保证大对象在年轻代回收，减小老年代缩短回收时间；
PS：两个可视化工具命令可以实现工具，让大家看的更加直观，并不是没有这些工具不行，而是有了这些工具更加方便。
Tomcat、Jetty、GlassFish 等等这系列 Web容器/应用服务器，虽然做为容器，提供的是一个 Java Web 的运行时环境，以支持Servlet/JSP 等等这些内容的运行，但我们都很清楚，其本质上还是一个 Java 应用程序。 每次对于 容器的启动运行，都是把这个 Java 程序跑起来，来实现 Web 容器的能力。
在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！
大家好，又见面了，我是你们的朋友全栈君。 如何判断JVM是否存在内存问题呢？判断JVM垃圾回收是否正常？一般的top指令基本上满足不了这样的需求，因为它主要监控的是总体的系统资源，很难定位到java应用程序。 Jstat是JDK自带的一个轻量级小工具。全称“Java Virtual Machine statistics monitoring tool”，它位于java的bin目录下，主要利用JVM内建的指令对Java应用程序的资源和性能进行实时的命令行的监控，包括了对Heap size和垃圾回收状况的监控。可见，Jstat是轻量级的、专门针对JVM的工具，非常适用。jstat工具特别强大，有众多的可选项，详细查看堆内各个部分的使用量，以及加载类的数量。使用时，需加上查看进程的进程id，和所选参数。
用以判断JVM是否存在内存问题呢？如何判断JVM垃圾回收是否正常？一般的top指令基本上满足不了这样的需求，因为它主要监控的是总体的系统资源，很难定位到java应用程序。
最近不少同学都在找工作，给大家分享一波我这边带的高薪就业训练营学生面试某知名自研公司一二面面试复盘记录，两轮面试均已通过。
但事实上，g1 由于他的诸多优势已经越来越多的受到 java 程序员的青睐，尤其在机器内存日益增大的今天，巨大的内存分区无疑会让 CMS 回收时间过长，而这已经成为程序员们无法忍受 CMS 最重要的一个原因。
1.1 jps 类似Linux的ps,但是jps只用于列出Java的进程 可以方便查看Java进程的启动类,传入参数和JVM参数等 直接运行,不加参数,列出Java程序的进程ID以及Main函数等
每次聊起性能测试，最后的终结话题就是怎么做优化。其实在Java的复杂项目中都会有内存不足问题、内存泄露问题、线程死锁问题、CPU问题。这些问题功能测试或者是小压力的情况下有可能并不明显，很容易被忽视。但是到了生产环境，问题就暴露了，各种非功能bug会让你头疼不已。
类似Linux的ps，但jps只列出Java进程。可方便查看Java进程的启动类、传入参数和JVM参数。直接运行，不加参数，列出Java程序的进程ID及Main函数名称。
这篇是最近重发的JVM调优相关的文章汇总，考虑到应该隶属于高并发的服务端优化系列，现在系列文章涉及到了这一块，为了完整性就汇总在一起来填补这块的内容。看过的可以忽略，建议收藏，万一后面有遇到可以做个参考。
https://www.baeldung.com/java-gc-logging-to-file
JDK 提供了一系列用于监控、诊断 Java 进程的工具，它们在 JDK 安装目录的 bin 目录下，有 jps、jcmd、jstack、jinfo、jmap 等。其中jmc、jconsole、jvisualvm 是 GUI 工具，其他大部分都是命令行工具。
垃圾回收日志（GC 日志）是 JVM 在进行垃圾回收时产生的日志记录。它包含了垃圾回收器的各种信息，如垃圾回收的类型、垃圾回收的时间、垃圾回收的阶段、回收的内存占比等。通过分析 GC 日志，我们可以了解垃圾回收器的行为和性能，并根据日志数据进行调优。
点击上方“芋道源码”，选择“设为星标” 管她前浪，还是后浪？ 能浪的浪，才是好浪！ 每天 10:33 更新文章，每天掉亿点点头发... 源码精品专栏 原创 | Java 2021 超神之路，很肝~ 中文详细注释的开源项目 RPC 框架 Dubbo 源码解析 网络应用框架 Netty 源码解析 消息中间件 RocketMQ 源码解析 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析 作业调度中间件 Elastic-Job 源码解析 分布式事务中间件 TCC-Transaction
大致方向：JVM调优的目的是保证在一定吞吐量的情况下尽可能的减少GC次数，从而减少系统停顿时间，提高服务质量和效率。
Java 开发人员肯定都知道 JDK的 bin 目录中有 “java.exe”、“javac.exe” 这两个命令行工具。下面主要介绍一些监视虚拟机和故障处理的工具。
1.1 JPS (JVM Process Status Tool)，查看当前机器上所有JVM进程的状态和启动参数
昨天上了马士兵老师的公开课第一节, 这节课前半部分基本上是对预习资料的巩固(还好我预习了)和延伸.这部分， 巩固的成分更高. 这节课的收获有如下:
该命令主要与jmap搭配使用，用来分析jmap转储的转储快照。其中构建了一个微型的http/html服务器。生成dump文件的分析结果后可以通过浏览器进行查看。 通常情况下不采用jhat进行分析，一方面，分析工作需要耗费额外的资源和时间，既然都要在其他机器进行，则不需要限定于上述工具。另外一方面，jhat界面比较简陋，可以用visualVM，eclipse的Memory Analizer 等更加专业的分析工具进行替换。
GC监控是为了鉴别JVM是否在高效地执行GC，以及是否有必要进行额外的性能调优。基于以上信息，我们可以修改应用程序或者调整GC算法（GC优化）。
Java HotSpot VM中-XX:的可配置参数列表进行描述；这些参数可以被松散的聚合成三类：
GC 优化的基本原则是：将不同的 GC 参数应用到两个及以上的服务器上然后比较它们的性能，然后将那些被证明可以提高性能或减少 GC 执行时间的参数应用于最终的工作服务器上。
JVM 11的优化指南：如何进行JVM调优，以及JVM调优参数有哪些”这篇文章将包含JVM 11调优的核心概念、重要性、调优参数，并提供12个实用的代码示例，每个示例都会结合JVM调优参数和Java代码
jmap是JDK自带的工具软件，主要用于打印指定Java进程(或核心文件、远程调试服务器)的共享对象内存映射或堆内存细节。可以使用jmap生成Heap Dump。在Java命令学习系列（零）——常见命令及Java Dump介绍和Java命令学习系列（二）——Jstack中分别有关于Java Dump以及线程 Dump的介绍。 这篇文章主要介绍Java的堆Dump以及jamp命令
思路：现象是阻塞，通常是 CPU 彪高，导致业务线程分配不到 CPU 时间片，或者内存吃紧，频繁 GC 导致的 STW。登录到目标服务器，由于 ES 的用户不是 LZ，因此找运维要了 root 权限，登录到服务器。sudo -i 切到 root，使用 ps -ef | grep Elasticsearch 找到该用户，然后 su - es 切到 es 用户（不切是无法处理 es 用户的 Java 进程的，例如打印 jstack 日志）。 top 查看服务器状态，发现 pid 4335 进程的 CPU 占用达到 180%，查看 CPU 核数：cat /proc/cpuinfo| grep “processor”| wc -l， 核数为 4，根据经验，通常是 C2 编译器，或者 GC 线程，最后是业务代码导致。因此需要定位该线程。使用 top -Hp 4335，得到线程号 30785，使用 printf "%x" 得到 16 进制数字 7841，方便在 jstack 日志查找线程。使用 jstack -l 4335 > jstacklog.txt 打印日志，然后找线程，vim jstacklog.txt, 开始查找，gg，/7841，enter，n， 找到 "Concurrent Mark-Sweep GC Thread" os_prio=0 tid=0x00007fd380063800 nid=0x7841 runnable 这个 CMS GC 线程，看来是内存不够了。 使用 jps -l 找到 es 启动类名称，然后使用 ps aux | grep Elasticsearch 找到启动详细信息，发现启动配置为 -Xmx2g -Xms2g, -XX:CMSInitiatingOccupancyFraction=50 ，这里为了防止串行 FGC，让 CMS 在 old 区达到 50% 时就开始 GC，所以 CMS 非常繁忙。为了验证此问题，使用 jstat -gcutil 4335 1000 查看 gc 状态，发现 fgc 频繁(5 秒一次)，ygc 正常（3 秒一次） ，这里说一下，CMS 的 fgc 此时和我们想象的不一样，CMS GC 只工作在老年代，每次 GC 会对 FGC 次数加 2，一次是 init mark，一次是 remark，这两个阶段会影响暂停应用，其他的清理阶段是并行清理的，对业务线程无影响，所以，当使用 CMS GC ，如果 jstat 看到 FGC 次数很多，不用在意。但当 CMS 出现 concurrent mode failure（CMS GC 的速度赶不上对象晋升到 old 区的速度），则会使用备用收集器 Serial，开始串行 GC，此时将会彻底 STW。 因此，这个 ES 将 CMS 的阈值调的很低，就是为了防止出现 concurrent mode failure。
说到 Java 虚拟机，不得不提的就是 Java 虚拟机的 GC（Garbage Collection）日志。而对于 GC 日志，我们不仅要学会看懂，而且要学会如何设置对应的 GC 日志参数。今天就让我们来学习一下 Java 虚拟机中所有与 GC 日志有关的参数。相信掌握了这些参数之后，对于大家线上打印 GC 日志是有不少帮助的。
CGI 服务发布到现网后，现网机器出现了Full GC告警，同时CPU飙高99%。在优先恢复现网服务正常后，开始着手定位Full GC的问题。
CGI 服务发布到现网后，现网机器出现了Full GC告警，同时CPU飙高99%。在优先恢复现网服务正常后，开始着手定位Full GC的问题。在现场只能够抓到四个GC线程占用了很高的CPU，无法抓到引发Full GC的线程。查看了服务故障期间的错误日志，发现更多的是由于Full GC引起的问题服务异常日志，无法确定Full GC的根源。为了查找问题的根源，只能从发布本身入手去查问题，发现一次bugfix的提交，有可能触发一个死循环逻辑：
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稳定增长，则有可能出现内存泄漏。
你可能用过ps命令，打印所有正在运行的进程的相关信息。JDK 中的jps命令。沿用了同样的概念：它将打印所有正在运行的 Java 进程的相关信息。
到目前为止，我们已经对 Jvm 进行了简单的了解，知道了 Jvm 运行时各种各样的内存结构，各种垃圾回收机制以及各种对应的垃圾收集器及其配置。而我们整个 Jvm 系列的最终目标不当仅仅以了解基础理论为终点，理论总应作为实践的工具。接下来，我们开始了解 Java 性能优化的最后一环：Jvm 性能调优。
程序在上线前的测试或运行中有时会出现一些大大小小的JVM问题，比如cpu load过高、请求延迟、tps降低等，甚至出现内存泄漏（每次垃圾收集使用的时间越来越长，垃圾收集频率越来越高，每次垃圾收集清理掉的垃圾数据越来越少）、内存溢出导致系统崩溃，因此需要对JVM进行调优，使得程序在正常运行的前提下，获得更高的用户体验和运行效率。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
