厉害了！不重启JVM，替换掉已经加载的类
在遥远的希艾斯星球爪哇国塞沃城中，两名年轻的程序员正在为一件事情苦恼，程序出问题了，一时看不出问题出在哪里，于是有了以下对话：
“Debug一下吧。”
“线上机器，没开Debug端口。”
“看日志，看看请求值和返回值分别是什么？”
“那段代码没打印日志。”
“改代码，加日志，重新发布一次。”
“怀疑是线程池的问题，重启会破坏现场。”
长达几十秒的沉默之后：“据说，排查问题的最高境界，就是只通过Review代码来发现问题。”
比几十秒长几十倍的沉默之后：“我轮询了那段代码一十七遍之后，终于得出一个结论。”
“结论是？”
Java对象行为
文章开头的问题本质上是动态改变内存中已存在对象的行为问题。
所以，得先弄清楚JVM中和对象行为有关的地方在哪里，有没有更改的可能性。
对象使用两种东西来描述事物：行为和属性。
举个例子：
public class Person{
private int age;
private String name;
public void speak(String str) {
System.out.println(str);
}
public Person(int age, String name) {
this.age = age;
this.name = name;
}
}
Person personA = new Person(43, "lixunhuan");
personA.speak("我是李寻欢");
Person personB = new Person(23, "afei");
personB.speak("我是阿飞");
Method area is created on virtual machine startup, shared among all Java virtual machine threads and it is logically part of heap area. It stores per-class structures such as the run-time constant pool, field and method data, and the code for methods and constructors.
java.lang.instrument.Instrumentation。”java.lang.instrument.Instrumentation
看完文档之后，我们发现这么两个接口：redefineClasses和retransformClasses。一个是重新定义class，一个是修改class。这两个大同小异，看redefineClasses的说明：
This method is used to replace the definition of a class without reference to the existing class file bytes, as one might do when recompiling from source for fix-and-continue debugging. Where the existing class file bytes are to be transformed (for example in bytecode instrumentation) retransformClasses should be used.
The redefinition may change method bodies, the constant pool and attributes. The redefinition must not add, remove or rename fields or methods, change the signatures of methods, or change inheritance. These restrictions maybe be lifted in future versions. The class file bytes are not checked, verified and installed until after the transformations have been applied, if the resultant bytes are in error this method will throw an exception.
我们能做的基本上也就是简单修改方法内的一些行为，这对于我们开头的问题，打印一段日志来说，已经足够了。当然，我们除了通过retransform来打印日志，还能做很多其他非常有用的事情，这个下文会进行介绍。
那怎么得到我们需要的class文件呢？一个最简单的方法，是把修改后的Java文件重新编译一遍得到class文件，然后调用redefineClasses替换。但是对于没有（或者拿不到，或者不方便修改）源码的文件我们应该怎么办呢？其实对于JVM来说，不管是Java也好，Scala也好，任何一种符合JVM规范的语言的源代码，都可以编译成class文件。JVM的操作对象是class文件，而不是源码。所以，从这种意义上来讲，我们可以说“JVM跟语言无关”。既然如此，不管有没有源码，其实我们只需要修改class文件就行了。
直接操作字节码
BTrace
在我们的工程中，谁来做这个寻找字节码，修改字节码，然后retransform的动作呢？我们并非先知，不可能知道未来有没有可能遇到文章开头的这种问题。考虑到性价比，我们也不可能在每个工程中都开发一段专门做这些修改字节码、重新加载字节码的代码。
如果JVM不在本地，在远程呢？
如果连ASM都不会用呢？能不能更通用一些，更“傻瓜”一些。
A safe, dynamic tracing tool for the Java platform.
package com.sun.btrace.samples;
import com.sun.btrace.annotations.*;
import com.sun.btrace.AnyType;
import static com.sun.btrace.BTraceUtils.*;
/**
* This sample demonstrates regular expression
* probe matching and getting input arguments
* as an array - so that any overload variant
* can be traced in "one place". This example
* traces any "readXX" method on any class in
* java.io package. Probed class, method and arg
* array is printed in the action.
*/
@BTrace public class ArgArray {
@OnMethod(
clazz="/java\\.io\\..*/",
method="/read.*/"
)
public static void anyRead(@ProbeClassName String pcn, @ProbeMethodName String pmn, AnyType[] args) {
println(pcn);
println(pmn);
printArray(args);
}
}
再来看另一个例子：每隔2秒打印截止到当前创建过的线程数。
package com.sun.btrace.samples;
import com.sun.btrace.annotations.*;
import static com.sun.btrace.BTraceUtils.*;
import com.sun.btrace.annotations.Export;
/**
* This sample creates a jvmstat counter and
* increments it everytime Thread.start() is
* called. This thread count may be accessed
* from outside the process. The @Export annotated
* fields are mapped to jvmstat counters. The counter
* name is "btrace." + <className> + "." + <fieldName>
*/
@BTrace public class ThreadCounter {
// create a jvmstat counter using @Export
@Export private static long count;
@OnMethod(
clazz="java.lang.Thread",
method="start"
)
public static void onnewThread(@Self Thread t) {
// updating counter is easy. Just assign to
// the static field!
count++;
}
@OnTimer(2000)
public static void ontimer() {
// we can access counter as "count" as well
// as from jvmstat counter directly.
println(count);
// or equivalently ...
println(Counters.perfLong("btrace.com.sun.btrace.samples.ThreadCounter.count"));
}
}
BTrace主要有下面几个模块：
BTrace脚本：利用BTrace定义的注解，我们可以很方便地根据需要进行脚本的开发。
Compiler：将BTrace脚本编译成BTrace class文件。
Client：将class文件发送到Agent。
Agent：基于Java的Attach API，Agent可以动态附着到一个运行的JVM上，然后开启一个BTrace Server，接收client发过来的BTrace脚本；解析脚本，然后根据脚本中的规则找到要修改的类；修改字节码后，调用Java Instrument的retransform接口，完成对对象行为的修改并使之生效。另外，搜索公众号互联网架构师后台回复“2T”，获取一份惊喜礼包。
整个BTrace的架构大致如下：
不允许创建对象
不允许创建数组
不允许抛异常
不允许catch异常
不允许随意调用其他对象或者类的方法，只允许调用com.sun.btrace.BTraceUtils中提供的静态方法（一些数据处理和信息输出工具）
不允许改变类的属性
不允许有成员变量和方法，只允许存在static public void方法
不允许有内部类、嵌套类
不允许有同步方法和同步块
不允许有循环
不允许随意继承其他类（当然，java.lang.Object除外）
不允许实现接口
不允许使用assert
不允许使用Class对象
Arthas
本文旨在说明Java动态追踪技术的来龙去脉，掌握技术背后的原理之后，只要愿意，各位读者也可以开发出自己的“冰封王座”出来。