能否通过JDI插装Object类？跟踪对象分配遇异常

Let’s break down your problems and walk through viable solutions step by step:

Did You Make Mistakes in Your Operations? #

None of your attempts were "wrong"—they ran into fundamental JVM limitations and common pitfalls with core class manipulation:

1. Java Agent + UnmodifiableClassException: This is expected behavior. Core JDK classes like java.lang.Object are marked as unmodifiable by the JVM for stability and security. The instrumentation API explicitly blocks transforming these classes, so this isn’t an error on your part—it’s a hard constraint.
2. JDI + StackOverflowError: The root cause here is a circular allocation loop. When you injected First.value += 1; into the Object constructor, if First.value is an Integer (or any reference type), incrementing it triggers auto-boxing (creating a new Integer instance), which calls the Object constructor again. This creates an infinite loop of allocation → constructor call → allocation, leading to stack overflow. Your "simple code" test worked because it didn’t trigger additional object allocations.
3. JDI + NoClassDefFoundError for Integer Constructor: Integer is another core JDK class with strict initialization dependencies. Modifying its constructor disrupts the JVM’s class loading order, preventing Integer from resolving properly. This reinforces that tweaking core classes via JDI is inherently risky.

Can You Modify java.lang.Object via JDI? #

Technically, JDI’s ClassType.redefineClasses() allows bytecode modification, but modifying Object is not practical or recommended. The JVM relies on Object’s internal structure and constructor behavior for fundamental operations. Even if you avoid immediate crashes, you’ll face:

• Unresolvable circular allocation loops
• Broken class initialization chains
• Incompatibilities with JVM optimizations (like escape analysis or inline caching)
• Varied behavior across JVM implementations (HotSpot, OpenJ9, GraalVM)

Most JVMs have implicit protections against modifying core classes via JDI, even if the API doesn’t explicitly block it.

Alternative Solutions Without JVMTI (C Code) #

If you want to track object allocations without writing native code, here are robust options:

1. Bytecode Enhancement of Non-Core Classes (Java Agent + ASM/ByteBuddy) #

Instead of modifying Object, enhance constructors of application-level and non-core library classes (which cover most object allocations):

• Use a Java Agent with a ClassFileTransformer
• Leverage libraries like ByteBuddy (simpler, high-level API) or ASM (low-level control) to inject tracking code into every constructor of non-core classes. For example, ByteBuddy lets you intercept constructor calls and increment your allocation counter with minimal boilerplate.
• For arrays: You can’t modify array "constructors" directly, but you can enhance methods that create arrays (e.g., new int[5] in application code) and use Instrumentation.getObjectSize() to estimate array sizes.

2. Programmatically Use JDK Flight Recorder (JFR) #

JFR has built-in events for object allocations. You can enable JFR via code, subscribe to jdk.ObjectAllocationInNewTLAB and jdk.ObjectAllocationOutsideTLAB events, and collect allocation data without modifying any bytecode. This is a low-overhead, built-in solution ideal if you don’t need custom tracking logic beyond what JFR provides.

3. Custom Allocation Wrappers (Controlled Environments) #

If you own the code being tracked, replace direct object creation with factory methods. For example, swap new MyClass() with Allocator.create(MyClass.class), where Allocator handles tracking. This is less invasive but only works for code you control.

内容的提问来源于stack exchange，提问作者Marek Tokarski