accesscontrolexception本质是java安全模型运行时拦截越权操作，表明当前执行上下文未被授权执行敏感行为（如读user.dir、文件i/o等），其决策基于调用栈逐层检查protectiondomain权限，遇doprivileged且权限匹配则放行，否则抛出异常。
AccessControlException 本质是 Java 安全模型在运行时“拦下”了一次越权操作。它不表示代码写错了，而是明确告诉你：当前执行上下文没有被授权做这件事——比如读系统属性、打开文件、加载本地库、访问网络等。关键不在“做了什么”，而在“谁在做、在哪做、有没有被准许”。
权限检查的链式决策过程
Java 的 AccessController 不是简单查一张白名单，而是按调用栈从上到下逐层审查：
- 最顶层（当前方法）发起权限请求，比如
System.getProperty("user.dir") - 检查调用链中每个类的 ProtectionDomain 是否包含对应权限（如
PropertyPermission "user.dir" "read"） - 遇到标记为
doPrivileged的调用方，且其域拥有该权限，检查立即终止并放行 - 若整条链都未满足，或某环节显式拒绝，就抛出
AccessControlException
常见触发场景与对应权限类型
不是所有敏感操作都会报这个错，只在启用 SecurityManager 时才激活。典型组合包括：
-
读系统属性：如
"user.dir"、"java.home"→ 需PropertyPermission（读/写） -
文件 I/O：打开、删除、列出目录 → 需
FilePermission（路径 + 操作，如"/tmp/-" "read,write,delete"） -
动态加载库：调用
System.loadLibrary→ 需RuntimePermission "loadLibrary.*" -
反射突破封装：
setAccessible(true)→ 需ReflectPermission "suppressAccessChecks"
策略文件配置要点
权限由 java.policy 或自定义策略文件控制，配置需注意粒度和来源：
- 使用
codeBase精确限定生效范围，避免宽泛的"file:-"引入风险 - 权限语句必须完整：类名、目标名、动作三者缺一不可，例如
permission java.util.PropertyPermission "user.dir", "read"; - 通配符要谨慎：
"*"可匹配所有属性，但"read,write"比单写"read"权限更大 - 启动时必须同时启用安全管理器：
java -Djava.security.manager -Djava.security.policy=my.policy MyApp
调试与验证建议
光改策略不一定见效，需确认实际生效的策略链和执行主体：
- 加 JVM 参数
-Djava.security.debug=access,failure，运行时会打印每一步权限检查结果 - 检查是否多个策略文件叠加导致冲突，可通过
Policy.getPolicy().getPermissions(ProtectionDomain)在代码中查看当前域实际获得的权限 - 容器环境（如 Tomcat、WebLogic）通常自带策略文件，优先修改其
weblogic.policy或catalina.policy，而非全局 policy - 若仅用于开发测试，可临时移除 SecurityManager：
System.setSecurityManager(null)，但切勿用于生产
