Java安全性核心是“默认限制、按需授权”,依托沙箱模型实现,含类加载器、字节码验证器、安全管理器(Java 21已移除)和访问控制器四层;现转向模块封装、JVM参数限制等实践。

Java 的安全性设计核心在于“默认限制、按需授权”,沙箱模型是实现这一理念的关键机制。
沙箱模型的基本结构
Java 沙箱最初在 Applet 时代被提出,目的是隔离不受信任的代码(如网页中下载的 Java 小程序),防止其访问本地文件系统、网络、进程等敏感资源。它由四层组成:
- 类加载器(ClassLoader):区分不同来源的类(如系统类、扩展类、应用类、远程下载类),为后续权限控制提供基础
- 字节码验证器(Bytecode Verifier):在类加载时检查字节码合法性,确保不违反 JVM 安全约束(如类型安全、栈溢出、非法跳转)
- 安全管理器(SecurityManager):运行时拦截危险操作(如 FileInputStream 构造、System.exit() 调用),依据策略文件(java.policy)决定是否放行
- 访问控制器(AccessController):配合安全管理器,基于栈帧进行权限检查(doPrivileged 块可临时提升权限)
权限模型与策略配置
Java 使用基于策略(Policy-based)的权限控制,而非角色或用户粒度。每个代码源(CodeSource)可被授予一组 Permission 实例,例如:
- FilePermission:"c:/data/*" "read,write"
- SocketPermission:"example.com:8080" "connect,resolve"
- RuntimePermission:"createClassLoader", "setSecurityManager"
策略可通过 Policy.getPolicy().refresh() 动态重载,也可在启动时指定:
java -Djava.security.manager -Djava.security.policy==my.policy MyApp
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
现代 Java 中的演进与限制
从 Java 17 开始,SecurityManager 已被标记为 @Deprecated for removal;Java 18 起默认禁用,Java 21 正式移除。原因包括:
立即学习“Java免费学习笔记(深入)”;
- Applet 技术淘汰,沙箱主要使用场景消失
- 安全管理器性能开销大,且难以与模块系统(JPMS)、容器化部署协同
- 实际生产环境更依赖操作系统级隔离(如容器、SELinux)、最小权限原则和代码审计
当前推荐的安全实践转向:模块封装(module-info.java 中的 opens/exports 控制)、JVM 启动参数限制(如 -XX:+DisableAttachMechanism)、以及使用 jlink 构建精简运行时镜像。
开发中仍需关注的安全点
即使不再启用 SecurityManager,以下设计习惯仍直接影响 Java 应用安全性:
- 避免使用 Class.forName() 或 Thread.currentThread().getContextClassLoader() 加载不可信类名
- 反序列化前校验输入来源,优先使用白名单机制(如 Jackson 的 @JsonCreator + 不可变对象)
- 敏感操作(如执行外部命令)应显式检查权限,必要时调用 AccessController.checkPermission()(仍可用,仅 SM 被移除)
- 使用 java.base 模块默认强封装,禁止通过反射绕过(--illegal-access=deny)

















