网站 怎么备案,东莞网站优化流程,网站制作金华公司电话,黄石做网站的公司当您需要从JVM内部收集数据时#xff0c;您会发现自己很危险地接近Java虚拟机内部进行工作。 幸运的是#xff0c;有一些方法可以避免被JVM实现细节所困扰。 Java之父没有给您提供过两个漂亮的工具供您使用。 在这篇文章中#xff0c;我们将说明两种方法之间的差异#xf… 当您需要从JVM内部收集数据时您会发现自己很危险地接近Java虚拟机内部进行工作。 幸运的是有一些方法可以避免被JVM实现细节所困扰。 Java之父没有给您提供过两个漂亮的工具供您使用。 在这篇文章中我们将说明两种方法之间的差异并说明为什么我们最近移植了算法的重要部分。 Java代理 第一种选择是使用java.lang.instrument接口。 这种方法使用-javaagent启动参数将监视代码加载到JVM本身。 作为Java的全部选择如果您的背景是Java开发那么javaagents往往是首选的方法。 说明您如何从该方法中受益的最佳方法是通过示例。 让我们创建一个真正简单的代理该代理将负责监视代码中的所有方法调用。 当代理面对方法调用时它将调用记录到标准输出流中 import org.objectweb.asm.*;public class MethodVisitorNotifyOnMethodEntry extends MethodVisitor {public MethodVisitorNotifyOnMethodEntry(MethodVisitor mv) {super(Opcodes.ASM4, mv);mv.visitMethodInsn(Opcodes.INVOKESTATIC, Type.getInternalName(MethodVisitorNotifyOnMethodEntry.class), callback, ()V);}public static void callback() {System.out.println(Method called!); }
} 您可以使用上面的示例将其打包为javaagent本质上是一个带有特殊MANIFEST.MF的小JAR文件然后使用类似于以下内容的代理的premain方法启动它 java -javaagent:path-to/your-agent.jar com.yourcompany.YourClass 启动后您会看到一堆“方法调用” 日志文件中的消息。 就我们而言仅此而已。 但是这个概念很强大尤其是与上面的示例中的字节码检测工具例如ASM或cgLib结合使用时。 为了使示例易于理解我们跳过了一些细节。 但这是相对简单的-使用java.lang.instrument包时您首先编写自己的代理类并实现public static void premainString agentArgsInstrumentation inst 。 然后您需要向inst.addTransformer注册您的ClassTransformer 。 您很可能希望避免直接对类字节码进行操作因此可以使用一些字节码操作库例如我们所使用的示例中的ASM。 有了它您只需要实现几个接口– ClassVisitor 为简便起见略过和MethodVisitor。 JVMTI 第二种方法最终将带您进入JVMTI。 JVM工具接口 JVM TI 是标准的本机API允许本机库捕获事件并控制Java虚拟机。 对JVMTI的访问通常打包在称为代理的特定库中。 下面的示例演示了与javaagent部分相同的回调注册但是这次将其实现为JVMTI调用 void JNICALL notifyOnMethodEntry(jvmtiEnv *jvmti_env, JNIEnv* jni_env, jthread thread, jmethodID method) {fputs(method was called!\n, stdout);
}int prepareNotifyOnMethodEntry(jvmtiEnv *jvmti) {jvmtiError error;jvmtiCapabilities requestedCapabilities, potentialCapabilities;memset(requestedCapabilities, 0, sizeof(requestedCapabilities));if((error (*jvmti)-GetPotentialCapabilities(jvmti, potentialCapabilities)) ! JVMTI_ERROR_NONE) return 0;if(potentialCapabilities.can_generate_method_entry_events) {requestedCapabilities.can_generate_method_entry_events 1;}else {//not possible on this JVMreturn 0;}if((error (*jvmti)-AddCapabilities(jvmti, requestedCapabilities)) ! JVMTI_ERROR_NONE) return 0;jvmtiEventCallbacks callbacks;memset(callbacks, 0, sizeof(callbacks));callbacks.MethodEntry notifyOnMethodEntry;if((error (*jvmti)-SetEventCallbacks(jvmti, callbacks, sizeof(callbacks))) ! JVMTI_ERROR_NONE) return 0;if((error (*jvmti)-SetEventNotificationMode(jvmti, JVMTI_ENABLE, JVMTI_EVENT_METHOD_ENTRY, (jthread)NULL)) ! JVMTI_ERROR_NONE) return 0;return 1;
} 两种方法之间存在一些差异。 例如通过JVMTI您可以获得比代理更多的信息。 但是两者之间最关键的区别在于加载机制。 在将Instrumentation代理加载到堆内部时它们由同一JVM进行管理。 JVMTI代理不受JVM规则支配因此不受JVM内部组件如GC或运行时错误处理的影响。 这意味着什么最好通过我们自己的经验来解释。 从-javaagent迁移到JVMTI 三年前当我们开始构建内存泄漏检测器时我们并没有过多地关注这些方法的优缺点。 我们毫不犹豫地将解决方案实现为-javaagent 。 多年来我们已经开始理解含义。 其中一些不太令人满意因此在我们的最新版本中我们将内存泄漏检测机制的重要部分移植到了本机代码。 是什么使我们跳到这样的结论 首先-当驻留在堆中时您需要将自己容纳在应用程序自己的内存结构旁边。 通过痛苦的经验中学到的东西本身就可能导致问题。 当您的应用程序已将堆填满到最大程度时您最后需要做的是一个内存泄漏检测器它似乎只会加快OutOfMemoryError的到达速度。 但是增加的堆空间减少了困扰我们的弊端。 真正的问题与以下事实有关使用受监视的应用程序本身正在使用的同一垃圾收集器清理了我们的数据结构。 这导致更长或更频繁的GC暂停。 尽管大多数应用程序不介意我们为堆消耗添加的几个额外的百分点但我们了解到需要消除对Full GC暂停产生不可预测的影响。 更糟糕的是– Plumbr的工作方式是监视所有对象的创建和集合。 监视某物时您需要保持跟踪。 跟踪往往会创建对象。 创建的对象将有资格使用GC。 现在当您监视的是GC时您刚刚创建了一个恶性循环-收集到更多的对象的垃圾创建的监视器越多触发的GC运行频率越高等等。 跟踪对象时JVMTI会通知我们有关对象死亡的信息。 但是JVMTI不允许在这些回调期间使用JNI。 因此如果我们使用Java保留有关跟踪对象的统计信息则当我们收到更改通知时不可能立即更新统计信息。 相反当我们知道JVM处于正确状态时需要将更改缓存并应用。 这造成了不必要的复杂性和更新实际统计数据的延迟。 翻译自: https://www.javacodegeeks.com/2014/03/migrating-from-javaagent-to-jvmti-our-experience.html
