该错误并非环境配置错误，而是JMockit在Java 9+模块化（JPMS）环境下因JVM attach机制变更引发的运行时限制，需显式启用-Djdk.attach.allowAttachSelf或配置-javaagent才能正常工作。
该错误并非环境配置错误，而是jmockit在java 9+模块化（jpms）环境下因jvm attach机制变更引发的运行时限制，需显式启用`-djdk.attach.allowattachself`或配置`-javaagent`才能正常工作。
你看到的错误信息中反复出现的 “Running on JDK 9 requires…” 并非说明你的项目实际运行在Java 9——它是一个典型的语义泛化表达：JDK官方文档与第三方库（如JMockit）普遍用“JDK 9”代指 JDK 9 及更高版本（≥9），因为Java 9是Java平台模块系统（JPMS）和java.lang.instrument/com.sun.tools.attach行为变更的分水岭。
从堆栈可见，错误源头明确指向 jmockit-1.n.jar，且触发路径为JUnit Platform测试类处理器（JUnitPlatformTestClassProcessor），说明问题发生在测试执行阶段，而非编译或IDE配置阶段。这与你在IntelliJ中看到的Project SDK、Module Language Level、External Libraries等设置完全无关——那些只影响编译与代码提示，而该错误属于JVM启动参数缺失导致的运行时拒绝服务。
? 根本原因：JPMS对动态attach的严格限制
Java 9起，出于安全强化，默认禁止JVM通过com.sun.tools.attach API对自己（self-attach）或祖先进程进行动态代理注入。而JMockit高度依赖此机制实现无侵入式Mock（如@Mocked、@Injectable）。因此，即使你使用的是Java 11或Java 17，只要未显式授权，就会抛出该IllegalStateException。
✅ 正确理解：
JDK 9=JDK ≥ 9，不是版本误配，而是功能启用开关未打开。立即学习“Java免费学习笔记（深入）”；
✅ 两种标准解决方案（任选其一）
方案一：添加JVM系统属性（推荐，轻量易维护）
在IntelliJ中为测试配置添加JVM选项：
- 打开 Run → Edit Configurations…
- 左侧选择你的测试配置（如
JUnit或Test） - 在 VM options 输入框中添加：
-Djdk.attach.allowAttachSelf=true
- 点击Apply → OK，重新运行测试。
? 优势：无需修改构建脚本，适用于本地调试；对Gradle/Maven构建无侵入。
Alibabacloud Sdk Client Initialization For Java下载在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
方案二：显式声明Java Agent（适合CI/统一管控）
若项目已集成JMockit依赖，需确保-javaagent路径正确，并在所有运行环境中生效：
Gradle（build.gradle）中配置：
test {
jvmArgs = ['-javaagent:' + System.getProperty('user.home') + '/.m2/repository/org/jmockit/jmockit/1.49/jmockit-1.49.jar']
// 或更健壮的写法（自动解析依赖路径）：
// jvmArgs = ['-javaagent:' + configurations.testRuntimeClasspath.files.find { it.name.contains('jmockit') }.absolutePath]
}Maven（pom.xml）中配置：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>3.0.0-M10</version>
<configuration>
<argLine>-javaagent:${settings.localRepository}/org/jmockit/jmockit/1.49/jmockit-1.49.jar</argLine>
</configuration>
</plugin>⚠️ 注意：
jmockit-1.49.jar路径需与你实际引入的版本一致；建议使用mvn dependency:copy-dependencies确认本地仓库路径。
? 常见误区与避坑提醒
- ❌ 不要试图降级JDK至8——既违背现代Java工程实践，也无法解决根本问题（JMockit 1.x本身已不兼容JDK 8的旧attach逻辑）；
- ❌ 不要修改
module-info.java或加--add-opens——此错误与模块导出无关，而是JVM底层attach权限控制； - ❌ 不要在
gradle.properties中设org.gradle.jvmargs来全局添加-Djdk.attach...——该参数仅作用于Gradle Daemon JVM，而非测试子进程； - ✅ 推荐长期演进：评估迁移到JUnit 5 Mocking Extensions或Mockito-inline，它们原生适配JPMS且无需Java Agent。
✅ 验证是否修复
成功添加配置后，再次运行测试，错误应消失，且JMockit功能（如@Mocked List<string></string>）可正常工作。你可在测试中加入简单断言验证：
@Test
public void testJMockitWorks() {
new Expectations() {{
mockedList.size(); result = 42;
}};
assertEquals(42, mockedList.size()); // 应通过
}记住：这不是一个“可以忽略的警告”，而是阻断测试执行的硬性失败。但它的修复成本极低——只需一行JVM参数。理解其背后的JPMS设计哲学，比机械地复制粘贴解决方案更有价值。
