SecurityException 由 SecurityManager 或受保护 API 主动抛出，非 JVM 自动触发；现代 JDK（9+）默认禁用 SecurityManager，仅在手动启用、旧环境或特定受限 API 调用时出现。
SecurityException 是谁抛出来的？
Java 的 SecurityException 不是 JVM 自动触发的通用错误，而是由 SecurityManager（如果启用）或某些受保护 API 主动检查后显式抛出的运行时异常。它本质是“访问被拒绝”的信号，不是代码写错了，而是策略拦住了。
现代 JDK（9+）默认不安装 SecurityManager，所以你几乎不会在普通应用里遇到它——除非你手动启用、跑在旧版 Applet 环境、用某些老框架（如早期 Spring Security 沙箱）、或调用特定受限 API（比如反射修改 final 字段、读取系统属性 java.home、打开 Socket 绑定特权端口）。
- 常见触发点：
System.setSecurityManager(new SecurityManager())后再执行敏感操作 - 典型场景：Applet、JNLP、RMI 服务端策略配置、自定义类加载器中对
defineClass的校验 - 注意：
SecurityException和AccessControlException（后者是前者的子类）在日志里常混用，但堆栈里看到的通常是SecurityException
如何定位具体哪行代码触发了 SecurityException？
关键看堆栈最顶端的 throw new SecurityException(...) 调用点，而不是你自己的业务代码行。它往往藏在 JDK 内部方法里，比如：
java.lang.SecurityException: Prohibited package name: java.lang
at java.base/java.lang.ClassLoader.preDefineClass(ClassLoader.java:915)
at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1015)
...这种提示说明你试图定义一个以 java. 开头的包名类——JDK 明令禁止，和安全策略文件无关，纯硬编码限制。
立即学习“Java免费学习笔记（深入）”；
- 先检查异常消息内容：
Prohibited package name、access denied ("java.util.PropertyPermission" "os.name" "read")这类字符串直接暴露被拒资源类型 - 若消息为空或模糊，加 JVM 参数
-Djava.security.debug=access,failure启用详细审计日志 - 不要只盯着你的
catch (SecurityException e)——它只是接收者，真正决策者在AccessController.checkPermission(...)或SecurityManager.checkXXX(...)调用链里
能否捕获并绕过 SecurityException？
可以捕获，但“绕过”需分情况——技术上能 suppress，逻辑上是否合理是另一回事。
- 捕获本身没问题：
try { System.setProperty("xxx", "y"); } catch (SecurityException e) { /* 忽略或降级处理 */ } - 不能通过 try-catch 让被禁操作成功执行；异常抛出意味着权限检查已失败，流程中断
- 若想让操作生效，必须改权限策略：编辑
$JAVA_HOME/conf/security/java.policy或用Policy.setPolicy(...)动态加载新策略 - 注意：生产环境动态 setPolicy 需已有足够权限，否则自己先抛
SecurityException
例如允许读取所有系统属性，需在 policy 文件中添加：
grant {
permission java.util.PropertyPermission "*", "read";
};Java 17+ 还需要关心 SecurityManager 吗？
基本不需要。JDK 17 将 SecurityManager 标记为 @Deprecated(forRemoval = true)，JDK 21 正式移除其核心支持。OpenJDK 已删除大部分 SecurityManager 相关字节码检查逻辑。
这意味着：
- 即使你调用
System.setSecurityManager(new SecurityManager())，多数敏感操作（如反射、类加载）也不再受控 -
SecurityException仍存在（作为历史异常类保留），但触发路径大幅收窄，主要剩少数遗留 API（如Runtime.exec在某些容器环境的封装层） - 新项目应转向更现代的安全模型：模块系统（
module-info.java的opens/exports控制）、JVM 启动参数（--add-opens）、OS 级沙箱（seccomp、namespaces）
真正容易被忽略的是：有些老库（尤其 2015 年前写的工具类）仍会无条件调用 System.getSecurityManager() 做空判断，升级 JDK 后可能因返回 null 导致 NPE，而非 SecurityException——这反而成了新坑。
