Arthas 是阿里开源的一款线上 Java 诊断神器,通过全局的视角可以查看应用程序的内存、GC、线程等状态信息,并且能够在不修改代码的情况下,对业务问题进行诊断,包括查看方法的参数调用、执行时间、异常堆栈等信息,大大提升了生产环境中问题排查的效率。
Arthas 的官方网站是 https://arthas.aliyun.com/doc/,目前最新的版本是 3.7.2。
![](https://cdn.tobebetterjavaer.com/stutymore/arthas-20240109102105.png)
Arthas 是阿里开源的一款线上 Java 诊断神器,通过全局的视角可以查看应用程序的内存、GC、线程等状态信息,并且能够在不修改代码的情况下,对业务问题进行诊断,包括查看方法的参数调用、执行时间、异常堆栈等信息,大大提升了生产环境中问题排查的效率。
Arthas 的官方网站是 https://arthas.aliyun.com/doc/,目前最新的版本是 3.7.2。
We are all in the gutter, but some of us are looking at the stars. (我们都生活在阴沟里,但仍有人仰望星空 )- 王尔德 《温德米尔夫人的扇子》
举世混浊我独清,众人皆醉我独醒 - 屈原 《楚辞》
ASM是一种通用Java字节码操作和分析框架。它可以用于修改现有的class文件或动态生成class文件。
**ASM **is an all purpose Java bytecode manipulation and analysis framework. It can be used to modify existing classes or to dynamically generate classes, directly in binary form. ASM provides some common bytecode transformations and analysis algorithms from which custom complex transformations and code analysis tools can be built. ASM offers similar functionality as other Java bytecode frameworks, but is focused onperformance. Because it was designed and implemented to be as small and as fast as possible, it is well suited for use in dynamic systems (but can of course be used in a static way too, e.g. in compilers).
计算机比较“傻”,只认 0 和 1,这意味着我们编写的代码最终都要编译成机器码才能被计算机执行。Java 在诞生之初就提出了一个非常著名的宣传口号: "一次编写,处处运行"。
Write Once, Run Anywhere.
为了这个口号,Java 的亲妈 Sun 公司以及其他虚拟机提供商发布了许多可以在不同平台上运行的 Java 虚拟机,而这些虚拟机都拥有一个共同的功能,那就是可以载入和执行同一种与平台无关的字节码(Byte Code)。
大家好,我是二哥呀,今天我拿了一把小刀,准备带大家解剖一下 Java 的类文件结构,也就是 .class 文件的内容结构,虽然它实际上是一串连续的二进制,由 0 和 1 组成,但我们仍然可以借助一些工具来看清楚它的真面目。
类文件结构=.class文件的结构=Class文件结构,这三个说法都是一个意思,.class是从文件后缀名的角度来说的,Class是从Java类的角度来说的,类文件结构就是 Class 的中文译名。
---这部分内容前面其实已经讲过,但为了保持这篇内容的完整性,就暂时保留了下来,已经掌握的同学可以略过 start----
上一节在讲 JVM 运行 Java 代码的时候,我们提到,JVM 需要将编译后的字节码文件加载到其内部的运行时数据区域中进行执行。这个过程涉及到了 Java 的类加载机制(面试常问的知识点),所以我们来详细地讲一讲。
很多小伙伴们做Java
开发,天天写Java
代码,肯定离不开Java
基础环境:JDK
,毕竟我们写好的Java
代码也是跑在JVM
虚拟机上。
一般来说,我们学Java
之前,第一步就是安装JDK
环境。这个简单啊,我们一般直接把JDK
从官网下载下来,安装完成,配个环境变量就可以愉快地使用了。
不过话说回来,对于这个天天使用的东西,我们难道不好奇这玩意儿它到底是怎么由源码编译出来的吗?
记得 2014 年我在写大宗期货交易平台的时候,遇到了一些棘手的问题,可能是因为我的并发编程知识掌握的不够扎实,导致出现了内存泄漏的问题。
当时排查了好久,用的工具就是 JDK 自带的 jconsole,之前也没有过类似的性能监控经验,就导致在查找问题的时候非常痛苦,至今印象深刻。
那今天我们就从工具篇出发,来看看这些命令行工具的具体使用方法,以及如何排查问题。
除了我们的老朋友 java 和 javac 命令,在 Java 的 bin 目录下,还有很多其他的命令行工具,比如说用于性能监控的 jps、jstat、jinfo、jmap、jstack、jcmd 等等。
前面给大家讲过一次 OOM 的优化排查实战,今天再给大家讲一个 CPU 100% 优化排查实战。
收到运维同学的报警,说某些服务器负载非常高,让我们开发定位问题。拿到问题后先去服务器上看了看,发现运行的只有我们的 Java 应用程序。于是先用 ps
命令拿到了应用的 PID
。
ps:查看进程的命令;PID:进程 ID。
ps -ef | grep java
可以查看所有的 Java 进程。前面也曾讲过。
以上三点构成不可能三角,即一款垃圾回收器不可能同时满足三点。随着硬件水平的提升,内存占用不再是我们关注的重点,评估垃圾回收器性能时,重点关注吞吐量和暂停时间。吞吐量和暂停时间是相互矛盾的,目前我们追求的效果是:在最大吞吐量优先的情况下,减小暂停时间。
垃圾回收对于 Java 党来说,是一个绕不开的话题,工作中涉及到的调优工作也经常围绕着垃圾回收器展开。面对不同的业务场景,往往需要不同的垃圾收集器才能保证 GC 性能,因此,对于面大厂或者有远大志向的球友可以卷一下垃圾收集器。
就目前来说,JVM 的垃圾收集器主要分为两大类:分代收集器和分区收集器,分代收集器的代表是 CMS,分区收集器的代表是 G1 和 ZGC,下面我们来看看这两大类的垃圾收集器。