Java SecurityManager 被禁用后，policy 文件还起作用吗
不起作用。从 Java 17 开始，SecurityManager 已被标记为 deprecated；Java 21 正式移除。只要没显式启用（比如启动时加 -Djava.security.manager），哪怕你写了 java.policy，JVM 根本不会加载它，更不会校验任何权限。
常见错误现象：改了 java.security 里的 policy.url，重启应用却没效果；或者看到 AccessControlException 但实际根本没触发——大概率是 SecurityManager 压根没开。
- 检查是否启用：
System.getSecurityManager()返回null就说明没启用 - 启用需加 JVM 参数：
-Djava.security.manager=allow（Java 17+）或-Djava.security.manager（旧版） - 注意：Spring Boot、Tomcat 等主流运行环境默认不启用，且多数现代框架不兼容
SecurityManager
如何让 JVM 加载自定义 policy 文件
即使启用了 SecurityManager，JVM 默认只读 $JAVA_HOME/conf/security/java.policy 和用户目录下的 .java.policy。要加载自己写的，必须显式指定路径。
使用场景：测试类加载器隔离、限制第三方 JAR 的文件读写、沙箱化执行脚本等。
立即学习“Java免费学习笔记（深入）”；
- 方式一（推荐）：启动时用
-Djava.security.policy=/path/to/my.policy - 方式二：在
$JAVA_HOME/conf/security/java.security中修改policy.url.1行，例如：policy.url.1=file:/etc/myapp.policy - 多个 policy 文件可叠加，用
policy.url.2继续追加，顺序靠前的优先级更高 - 路径必须是
file:协议，http:或相对路径（如./my.policy）会被忽略
policy 文件里 grant 块写错权限的典型表现
权限配置语法脆弱，一个字母错就整个 grant 块失效，而且 JVM 不报错，只是静默跳过。
常见错误现象：AccessControlException: access denied ("java.io.FilePermission" "/tmp/test.txt" "read")，但 policy 文件里明明写了对应权限。
-
permission后面必须跟全限定类名，比如java.io.FilePermission，不能写成FilePermission - 路径字符串中，
">"是合法通配符，但"*"或"**"不是；Windows 路径要用双反斜杠"C:\temp\*" - 动作列表必须用英文逗号分隔且无空格：
"read,write"✅，"read, write"❌ - 如果用了
signedBy，证书别名必须和 JAR 签名时的-alias完全一致，大小写敏感
Java 17+ 还值得花时间配 policy 文件吗
绝大多数情况下不值得。除了极少数遗留系统或硬性合规要求（如某些金融沙箱），真实项目里已基本弃用这套机制。
替代方案更直接有效：
- 文件访问控制交给操作系统或容器（如 Docker 的
--read-only、--tmpfs） - 网络限制用防火墙或服务网格（如 Istio 的 mTLS + 策略）
- 敏感操作走统一鉴权中间件，而不是靠 JVM 层面的
checkPermission - 若真需动态权限控制，用
SecurityManager的替代品如java.lang.SecurityManager的继任者——目前没有官方替代，社区方案也极少维护
真正容易被忽略的是：很多人还在文档里查 java.security 配置项，却没意识到这些参数在 SecurityManager == null 时全是摆设。先确认是否启用，再动 policy，否则所有配置都是白忙。
