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