Instrumentation接口设计初衷是为了收集Java程序运行时的数据,用于监控运行程序状态,记录日志,分析代码用的。接下来从源码的流程来介绍一下
实现类InstrumentationImpl的 void addTransformer(ClassFileTransformer transformer, boolean canRetransform);
从这段代码知道,转换器ClassFileTransformer的实现是存储在TransformerManager的TransformerInfo数组中的,数组初始长度为0,每添加一个,数组长度为原来的长度+1,将原数组内容拷贝到新数组中。
进入 AttachProvider.providers()
,这里面会初始化 AttachProvider
,并返回一个 AttachProvider List
。
进入 ServiceLoader.load(AttachProvider.class, AttachProvider.class.getClassLoader());
继续跟进方法 new LazyIterator(service, loader)
看一下 com.sun.tools
jar包下的 META-INF/services/
目录,打开 com.sun.tools.attach.spi.AttachProvider
, 可以看到有不同平台操作系统的实现,我的是windows,会调用windos的实现 sun.tools.attach.WindowsAttachProvider
。其他的都被注释掉了。代码看到这,就知道ServiceLoader.load方法最终加载的是 sun.tools.attach.WindowsAttachProvider
。
上文 hasNextService()
方法下面的 nextService()
回到最初的 VirtualMachine.attach(String var0)
方法,进入 return var4.attachVirtualMachine(var0);
的 attachVirtualMachine()
内
通过 ClassLoader 类中的 findNative
方法,可以找到JVM源码中的一些native方法调用名,这样可以关联着JVM源码看底层的C++源码到底做了啥
发现在attach.dll中找方法名为 Java_sun_tools_attach_WindowsVirtualMachine_openProcess
native method
尝试性的在jdk源码里去找这2个方法 Java_sun_tools_attach_WindowsVirtualMachine_openProcess
和 Java_sun_tools_attach_WindowsVirtualMachine_enqueue
virtualMachine.loadAgent()、 virtualMachine.detach()
源码流程和上述类似,也和平台相关,这里就不在赘述了。