Eclipse条件断点触发ObjectCollectedException，如何排查？

Let's walk through practical steps to diagnose and resolve this issue, since the current error log only points to a JDI-level garbage collection conflict.

The Scenario #

You're hitting a com.sun.jdi.ObjectCollectedException when setting a conditional breakpoint in Eclipse with this condition:

"String Literal".equals( stringWhichIsInScope )

Here's the full error from your .metadata/.log:

!ENTRY org.eclipse.jdt.debug 4 125 2019-04-29 14:31:48.928
!MESSAGE Internal error logged from JDI Debug:
!STACK 0
com.sun.jdi.ObjectCollectedException
at org.eclipse.jdi.internal.MirrorImpl.defaultReplyErrorHandler(MirrorImpl.java:282)
at org.eclipse.jdi.internal.ObjectReferenceImpl.disableCollection(ObjectReferenceImpl.java:104)
at org.eclipse.jdt.internal.debug.core.model.JDIObjectValue.disableCollection(JDIObjectValue.java:566)
at org.eclipse.jdt.internal.debug.eval.ast.engine.Interpreter.disableCollection(Interpreter.java:119)
at org.eclipse.jdt.internal.debug.eval.ast.engine.Interpreter.push(Interpreter.java:104)
at org.eclipse.jdt.internal.debug.eval.ast.instructions.Instruction.pushNewValue(Instruction.java:184)
at org.eclipse.jdt.internal.debug.eval.ast.instructions.PushString.execute(PushString.java:29)
at org.eclipse.jdt.internal.debug.eval.ast.engine.Interpreter.execute(Interpreter.java:69)
at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine$EvalRunnable$1EvaluationRunnable.run(ASTEvaluationEngine.java:705)
at org.eclipse.jdt.internal.debug.core.model.JDIThread.runEvaluation(JDIThread.java:840)
at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine$EvalRunnable.run(ASTEvaluationEngine.java:758)
at org.eclipse.jdt.internal.debug.core.model.JDIThread$ThreadJob.run(JDIThread.java:3603)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)

Diagnostic Steps & Checks to Try #

• Rewrite the conditional breakpoint logic
  Swap the comparison order and add a null check to avoid accessing a potentially collected object:

  stringWhichIsInScope != null && stringWhichIsInScope.equals("String Literal")
  

  If you know the string comes from the constant pool, you can also try reference equality ("String Literal" == stringWhichIsInScope)—this skips the method call entirely, reducing the chance of hitting a collected object.

• Verify the variable's lifecycle
  Double-check where stringWhichIsInScope is declared and used. Could the variable go out of scope or get set to null before the breakpoint triggers? JVMs sometimes aggressively garbage collect objects that aren't used later in the code, even if the line number is technically within the variable's scope.

• Disable GC optimization for debug objects
  In Eclipse, open your run/debug configuration, navigate to the Debugger tab, and look for an option like Disable garbage collection for debug objects. Enabling this tells the debugger to hold onto debug-related objects, preventing them from being collected while evaluating breakpoints.

• Update Eclipse and your JDK
  This exception often stems from bugs in older versions of Eclipse's JDT debugger or the JDK's JDI implementation. Try upgrading Eclipse to the latest stable release available (for 2019, that would be 2019-06 or newer) and use a recent, stable JDK build (like JDK 8u201+ or JDK 11 GA). Many debugging-related bugs get fixed in newer releases.

• Reset your Eclipse workspace metadata
  Corrupted metadata can cause odd debugging issues. Close Eclipse, back up the .metadata folder in your workspace, delete the original, then restart Eclipse and re-import your project. This resets all workspace-specific debug configurations and caches.

• Simplify your debug launch parameters
  If you're using custom JVM debug flags (like -Xdebug or custom jdwp agent settings), switch to Eclipse's default generated debug parameters. Custom flags can sometimes conflict with Eclipse's debugger implementation.

• Test with a minimal reproduction case
  Create a tiny test project with just the bare code needed to trigger the breakpoint (e.g., a single class declaring stringWhichIsInScope and setting the same conditional breakpoint). If the error doesn't occur here, the issue is likely tied to something specific in your original project—like complex class loading, custom GC settings, or unusual object lifecycle management.

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