上次做项目的时候，遇到个破事。一个老系统用SecurityManager做安全控制，代码里到处都是System.getSecurityManager().checkPermission()这种调用，看着就头疼。后来要升级到JDK 17，发现SecurityManager已经被废弃了，编译的时候一堆警告，运行的时候还报错，搞得焦头烂额。
鹏磊我后来一查，发现SecurityManager从JDK 17开始就被废弃了，JDK 24直接给移除了。这玩意儿是Java早期设计的，用来做沙箱安全控制，但设计有问题，用起来麻烦，性能还差，现在基本没人用了。现代Java应用都用容器隔离、操作系统权限控制这些更现代的安全机制，SecurityManager早就过时了。
现在好了，JDK 24的JEP 486（安全管理器永久禁用）终于把这个历史包袱给清理了。这个特性彻底移除了SecurityManager，不再支持-Djava.security.manager参数，代码里用SecurityManager的地方都会报错。虽然可能影响一些老代码，但这是好事，逼着大家用更现代的安全实践。兄弟们别磨叽，咱这就开始整活，把这个特性给整明白。
什么是SecurityManager
先说说啥是SecurityManager。SecurityManager是Java早期设计的安全机制，用来做沙箱安全控制。它的基本思想是：每个敏感操作都要先检查权限，如果没权限就抛SecurityException。
SecurityManager的工作方式是：代码里调用System.getSecurityManager().checkPermission()检查权限，SecurityManager根据安全策略文件（policy file）判断是否有权限。如果有权限就继续执行，没权限就抛异常。
// 老代码示例：使用SecurityManager
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new FilePermission("/tmp/test.txt", "read"));
}
// 如果没权限，checkPermission会抛SecurityException
但SecurityManager有个问题：设计太复杂，用起来麻烦，性能还差。而且现代Java应用都用容器隔离、操作系统权限控制这些更现代的安全机制，SecurityManager早就过时了。
JEP 486 的核心变更
JEP 486是JDK 24引入的一个特性，主要做了这么几件事：
- 移除SecurityManager：彻底移除了
java.lang.SecurityManager类，代码里用SecurityManager的地方都会报错 - 移除相关API：移除了SecurityManager相关的API，比如
System.getSecurityManager()、System.setSecurityManager()等 - 移除安全策略：不再支持安全策略文件（policy file），
-Djava.security.policy参数失效 - 移除启动参数：不再支持
-Djava.security.manager参数，设置这个参数会报错 - 现代化安全：鼓励使用容器隔离、操作系统权限控制等更现代的安全机制
这个特性是破坏性变更，会影响一些老代码。但这是好事，逼着大家用更现代的安全实践，长期来看是正向的。
SecurityManager的问题
SecurityManager为啥要被移除？鹏磊我觉得主要有这么几个问题：
1. 设计复杂
SecurityManager的设计太复杂，用起来麻烦。要配置安全策略文件，要理解权限模型，要处理各种边界情况，学习成本高，容易出错。
2. 性能差
SecurityManager每次检查权限都要遍历调用栈，性能差。特别是那种频繁检查的场景，性能影响明显。
3. 使用率低
现代Java应用基本不用SecurityManager了。Web应用用容器隔离，桌面应用用操作系统权限控制，SecurityManager早就过时了。
4. 维护成本高
SecurityManager的代码复杂，维护成本高。而且现在基本没人用，留着也没意义，不如移除。
迁移指南
如果代码里用了SecurityManager，需要迁移。鹏磊我总结了一下迁移方法：
1. 移除SecurityManager检查
最简单的方法就是直接移除SecurityManager检查。现代Java应用不需要SecurityManager，直接移除就行。
// 老代码：使用SecurityManager
public void readFile(String path) {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new FilePermission(path, "read"));
}
// 读取文件
Files.readAllLines(Paths.get(path));
}
// 新代码：直接移除SecurityManager检查
public void readFile(String path) throws IOException {
// 直接读取文件，不需要SecurityManager检查
// 安全控制由容器或操作系统负责
Files.readAllLines(Paths.get(path));
}
2. 使用容器隔离
现代Java应用用容器隔离做安全控制，比如Docker、Kubernetes这些。容器可以限制资源使用、网络访问、文件系统访问等，比SecurityManager更灵活、更安全。
# Docker容器示例：限制资源使用
docker run --memory="512m" --cpus="1.0" myapp
# Kubernetes示例：使用SecurityContext限制权限
apiVersion: v1
kind: Pod
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 2000
containers:
- name: myapp
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
3. 使用操作系统权限控制
桌面应用可以用操作系统权限控制，比如Linux的SELinux、AppArmor，macOS的Gatekeeper，Windows的UAC等。这些机制比SecurityManager更成熟、更安全。
# Linux SELinux示例：限制应用权限
# 创建SELinux策略文件
cat > myapp.te <<EOF
module myapp 1.0;
require {
type unconfined_t;
class file { read write };
}
allow unconfined_t unconfined_t:file { read write };
EOF
# 编译和安装策略
checkmodule -M -m -o myapp.mod myapp.te
semodule_package -o myapp.pp -m myapp.mod
semodule -i myapp.pp
4. 使用Java模块系统
Java 9引入的模块系统（JPMS）可以提供一定的安全控制，比如限制模块访问、导出包等。虽然不如SecurityManager灵活，但更简单、更现代。
// module-info.java：定义模块权限
module com.example.myapp {
requires java.base;
exports com.example.api; // 只导出API包
// 其他包不导出，外部模块无法访问
}
实际应用场景
SecurityManager被移除后，不同场景的替代方案：
1. Web应用
Web应用用容器隔离做安全控制，比如Docker、Kubernetes。容器可以限制资源使用、网络访问、文件系统访问等。
// Web应用示例：不需要SecurityManager
@RestController
public class MyController {
@GetMapping("/api/data")
public String getData() {
// 直接访问数据，不需要SecurityManager检查
// 安全控制由容器负责
return "data";
}
}
容器配置：
# Kubernetes Deployment示例
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp
spec:
template:
spec:
securityContext:
runAsNonRoot: true
runAsUser: 1000
fsGroup: 2000
containers:
- name: myapp
image: myapp:latest
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
readOnlyRootFilesystem: true
2. 桌面应用
桌面应用用操作系统权限控制，比如Linux的SELinux、AppArmor，macOS的Gatekeeper，Windows的UAC等。
// 桌面应用示例：不需要SecurityManager
public class DesktopApp {
public void saveFile(String path, String content) throws IOException {
// 直接保存文件，不需要SecurityManager检查
// 安全控制由操作系统负责
Files.write(Paths.get(path), content.getBytes());
}
}
操作系统配置：
# Linux AppArmor示例：限制应用权限
# 创建AppArmor配置文件
cat > /etc/apparmor.d/myapp <<EOF
#include <tunables/global>
/myapp {
#include <abstractions/base>
/tmp/** rw,
/home/user/** rw,
deny /etc/** r,
}
EOF
# 加载配置
sudo apparmor_parser -r /etc/apparmor.d/myapp
3. 命令行工具
命令行工具用操作系统权限控制，运行在受限用户下，限制文件系统访问、网络访问等。
// 命令行工具示例：不需要SecurityManager
public class CliTool {
public static void main(String[] args) {
// 直接执行操作，不需要SecurityManager检查
// 安全控制由操作系统负责
System.out.println("Hello, World!");
}
}
运行配置：
# 以受限用户运行
sudo -u restricted-user java -jar mytool.jar
# 使用chroot限制文件系统访问
sudo chroot /var/chroot java -jar mytool.jar
兼容性处理
如果代码里用了SecurityManager，需要处理兼容性。鹏磊我建议这么处理：
1. 检查代码
先用工具检查代码里有没有用SecurityManager，比如用grep搜索SecurityManager、getSecurityManager、setSecurityManager等。
# 搜索SecurityManager使用
grep -r "SecurityManager" src/
grep -r "getSecurityManager" src/
grep -r "setSecurityManager" src/
grep -r "checkPermission" src/
2. 逐步迁移
不要一下子全改，逐步迁移。先改新代码，再改老代码。或者先改不重要的代码，再改重要的代码。
3. 测试验证
迁移后要测试验证，确保功能正常。特别是那种依赖SecurityManager的代码，要重点测试。
// 测试示例：验证SecurityManager移除后的行为
public class SecurityManagerTest {
@Test
public void testSecurityManagerRemoved() {
// JDK 24中，getSecurityManager应该返回null或抛异常
try {
SecurityManager sm = System.getSecurityManager();
// 如果SecurityManager被移除，这里可能会抛异常
assertNull(sm);
} catch (NoClassDefFoundError e) {
// SecurityManager类不存在，这是正常的
assertTrue(true);
}
}
}
最佳实践
迁移到现代化安全实践的时候，鹏磊我建议注意这么几点：
1. 使用容器隔离
Web应用用容器隔离做安全控制，比如Docker、Kubernetes。容器可以限制资源使用、网络访问、文件系统访问等，比SecurityManager更灵活、更安全。
2. 使用操作系统权限控制
桌面应用和命令行工具用操作系统权限控制，比如Linux的SELinux、AppArmor，macOS的Gatekeeper，Windows的UAC等。
3. 使用最小权限原则
遵循最小权限原则，只给应用必要的权限。不要给应用root权限，不要给应用不必要的文件系统访问权限。
4. 定期审查权限
定期审查应用权限，看看有没有不必要的权限。如果发现不必要的权限，及时移除。
5. 监控安全事件
监控安全事件，及时发现和处理安全问题。可以用日志、监控工具等。
常见问题
Q1: SecurityManager被移除后，怎么保证应用安全？
用容器隔离、操作系统权限控制等更现代的安全机制。这些机制比SecurityManager更成熟、更安全。
Q2: 老代码用了SecurityManager，怎么办？
需要迁移。移除SecurityManager检查，用容器隔离或操作系统权限控制替代。
Q3: SecurityManager被移除会影响性能吗？
不会。SecurityManager被移除后，不再有权限检查的开销，性能可能会提升。
Q4: 什么时候应该迁移？
建议现在就迁移，特别是要升级到JDK 24的应用。JDK 24已经移除了SecurityManager，不迁移会报错。
Q5: 迁移后怎么测试？
测试功能是否正常，特别是那种依赖SecurityManager的代码。可以用单元测试、集成测试等。
总结
安全管理器永久禁用（JEP 486）是JDK 24引入的一个特性，彻底移除了SecurityManager，不再支持安全策略文件和启动参数。虽然可能影响一些老代码，但这是好事，逼着大家用更现代的安全实践。
SecurityManager设计复杂、性能差、使用率低、维护成本高，早就该移除了。现代Java应用用容器隔离、操作系统权限控制等更现代的安全机制，比SecurityManager更灵活、更安全。
迁移要注意使用容器隔离、操作系统权限控制、最小权限原则、定期审查权限、监控安全事件。虽然迁移可能有点麻烦，但长期来看是正向的，安全性更好，性能更好，维护成本更低。
虽然SecurityManager被移除了，但安全不能放松。要用更现代的安全实践，比如容器隔离、操作系统权限控制等，才能保证应用安全。兄弟们可以试试，特别是那种还在用SecurityManager的老代码，赶紧迁移吧。现代化安全是个长期工作，能提前准备就提前准备，等出问题了再准备就晚了。