securitymanager 无法拦截 new thread 越权，因其 checkaccess(thread) 等方法仅在启动系统线程、修改线程组或获取栈跟踪等特定操作时被 jvm 主动调用；而 new thread() 和 start() 仅为普通对象创建与调度，不触发任何安全检查。
Java 17 起 SecurityManager 已被标记为 deprecated for removal，JDK 21+ 默认禁用，JDK 25 中该类虽仍存在但不参与默认安全决策流程。因此，“通过配置严格的 SecurityManager 防止 new Thread 越权”这一思路在现代 JVM（尤其 Loom 环境）中技术上已不可行且官方不支持。
为什么 SecurityManager 无法拦截 new Thread 越权？
SecurityManager 的 checkXXX 方法（如 checkAccess(Thread)）仅在特定敏感操作时被 JVM 主动调用，例如：
• 启动系统线程（如 Thread.currentThread().stop()）
• 修改线程组（ThreadGroup.destroy()）
• 访问线程的栈跟踪（Thread.getStackTrace()）
但 new Thread() 或 Thread.start() 本身不触发任何 SecurityManager 检查——它只是对象创建与调度请求，JVM 视其为普通 Java 操作。
真正有效的越权防护路径：从线程创建转向执行上下文管控
业务代码能 new Thread，不代表它能安全访问敏感数据。防护重心应从“阻断线程创建”转向“切断非法上下文继承”和“限制运行时权限”：
-
禁用 ThreadLocal 泄漏：虚拟线程复用频繁，未清理的
ThreadLocal<securitycontext></securitycontext>可能跨请求泄露管理员身份。改用ScopedValue<userprincipal></userprincipal>（JDK 21+），确保每次任务携带显式、不可篡改的身份凭证 -
拒绝继承敏感状态：构建虚拟线程工厂时明确禁用继承：
Thread.ofVirtual().allowSetThreadLocals(false).inheritInheritableThreadLocals(false)
这能阻止子线程自动获得父线程的 MDC、事务上下文或认证令牌 -
策略级资源访问控制：敏感数据访问（如读取数据库密钥表、调用支付核验接口）必须走统一鉴权门面，例如：
• Spring Security 的@PreAuthorize("hasRole('ADMIN') and #id == principal.id")
• 自定义注解 + AOP，在方法入口校验当前ScopedValue.get()身份与操作目标的归属关系 -
JVM 层强制模块隔离：使用
--limit-modules java.base,jdk.unsupported和--add-opens精确开放必要包，使业务模块无法反射访问java.lang.SecurityManager或核心安全类，从根源消除绕过尝试
若仍需兼容旧环境（JDK 8–16），最小化 SecurityManager 作用域
仅当运行于严格受限的遗留沙箱（如某些金融中间件容器）时，可启用 SecurityManager，但绝不用于拦截 new Thread，而聚焦于其真实生效点：
- 在
policy文件中禁止危险反射：permission java.lang.RuntimePermission "accessDeclaredMembers"; - 限制文件/网络等底层资源：
permission java.io.FilePermission "/data/secrets/-", "read";permission java.net.SocketPermission "10.10.1.1:8080", "connect,resolve"; - 配合
-Djava.security.manager=allow启动，并确保业务代码无System.setSecurityManager(null)调用
靠 SecurityManager 拦 new Thread 是方向性错误。现代防护依赖的是上下文显式传递、执行时动态鉴权、模块边界硬隔离三者协同。线程怎么建不重要，关键是谁在什么上下文中调用了什么敏感操作。
