SecurityManager 自 Java 17 默认禁用、Java 21 彻底移除，因其栈遍历权限检查性能差、模型僵硬且不兼容模块系统等现代特性；应改用 JVM 参数限制、模块系统、容器隔离及编译期安全管控。
在 Java 中早已被标记为
，自 Java 17 起默认禁用，Java 21 中彻底移除。它不是当前推荐的安全控制机制，**不要在新项目中启用或依赖它**。
为什么 SecurityManager 被废弃
该机制基于运行时栈遍历做权限检查，性能开销大、模型僵硬、难以调试，且无法覆盖现代 Java 特性（如模块系统、JNI、反射增强、JVM TI 等）。主流应用服务器（Tomcat、Jetty）、框架（Spring）和云环境早已弃用它多年。
替代 SecurityManager 的实际做法
真正可控的安全边界已下沉到更底层或前移到开发/部署阶段：
JVM 启动参数限制
：用
禁止
js
tack/jmap 连接，
已无效
模块系统（JPMS）
：通过
显式导出包、限制服务使用，例如
安全管理工具链
：用
分析依赖风险，
构建最小化运行镜像
容器与平台层隔离
：Docker 的
、
、Kubernetes 的
比代码级沙箱更有效
遇到 SecurityManager 相关错误怎么办
常见于老代码升级或遗留测试中，典型现象包括：
启动报错：
调用
直接抛
JUnit 测试里用
误触发旧安全检查
解决方式统一：删掉所有
调用，移除
文件，改用以下任一方式补位：
立即学习
“
Java免费学习笔记（深入）
”；
Eclipse导入Android或其他的JAVA项目的正确方法 WORD版
本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
若需模拟权限失败场景（如测试文件拒绝），改用临时文件系统（
+
）或 mock
。
唯一还可能见到 SecurityManager 的地方
仅限极少数特殊场景：
嵌入式脚本引擎（如 Nashorn 遗留系统）或定制 JVM（如某些金融交易中间件的私有 JDK 分支）
。即便如此，也基本改用
字节
码校验（ASM/BCEL）、白名单类加载器或独立 sandbox 进程实现。
真正的安全控制不在“拦住代码执行”，而在“不让危险代码进来”——编译期检查、依赖扫描、镜像签名、运行时行为审计（如 OpenTelemetry + eBPF）才是当前重点。
SecurityManager@Deprecated(forRemoval = true)-XX:+DisableAttachMechanism-Djava.security.manager=allowmodule-info.javarequires static java.logging;jdeps --check=...jlink --no-jre-classes--read-only--cap-drop=ALLsecurityContextjava.lang.UnsupportedOperationException: Security Manager is no longer supportedSystem.setSecurityManager(new SecurityManager())UnsupportedOperationException@Rule public final ExpectedSystemExit exit = ExpectedSystemExit.none();setSecurityManagerjava.policyif (System.getSecurityManager() != null) {
// 此分支在 Java 17+ 永远不执行，可直接删除整段
}Files.createTempDirectory(...)setReadOnly()FileSystem