如果你经常阅读源码，你会发现 java 的源码中到处都有类似于下面这一段代码
class file {
  // 判断一个磁盘文件是否存在
  public boolean exists() {
    securitymanager security = system.getsecuritymanager();
    if (security != null) {
      security.checkread(path);
    }
    ...
  }
}

这明显是一个安全检查代码，检查的是你是否有访问磁盘路径的权限，为什么 java 语言需要这样的安全检查代码呢？我们再看看客户端套接字的 connect 函数源码，它需要检查用户是否有connect 某个网络地址的权限
class socket {
  public void connect(socketaddress endpoint, int timeout) {
    ...
    securitymanager security = system.getsecuritymanager();
    if (security != null) {
       if (epoint.isunresolved())
          security.checkconnect(epoint.gethostname(), port);
       else
          security.checkconnect(addr.gethostaddress(), port);
       }
    }
    ...
  }
}

再看服务端套接字的源码，它会检查端口的监听权限
class serversocket {
  public void bind(socketaddress endpoint, int backlog) {
    ...
    securitymanager security = system.getsecuritymanager();
    if (security != null)
       security.checklisten(epoint.getport());
    ...
  }
}

似乎所有和 io 操作有关的方法调用都需要进行安全检查。看起来io操作相关的权限检查是可理解的，用户进程不能随意访问所有的io资源。但是连环境变量都不让随意读，而且限制的还不是所有环境变量，而是某个具体的环境变量，这安全检查是不是有点过了？
class system {
  public static string getenv(string name) {
    securitymanager sm = getsecuritymanager();
    if (sm != null) {
       sm.checkpermission(new runtimepermission(getenv.+name));
    }
    return processenvironment.getenv(name);
  }
}

这是因为 java 的安全检查管理器和操作系统的权限检查不是一个概念，java 编写的不只是服务端应用程序，它还可以作为客户端跑在浏览器上（applet），它还可以以 app 的形式跑在手机上（j2me）,针对不同的平台 jvm 会使用不同的安全策略。通常情况下，针对 applet 的限制非常严格，一般不允许 applet 操作本地文件。执行具体 io 操作前，一旦 java 的安全检查通过，操作系统仍会进行权限检查。
我们平时在本地运行 java 程序时通常都不会默认打开安全检查器，需要执行 jvm 参数才会打开
$ java -djava.security.manager xxx
$ java -djava.security.manager -ddjava.security.policy=${policypath}

因为安全限制条件可以定制，所以还需要提供具体的安全策略文件路径，默认的策略文件路径是 java_home/jre/lib/security/java.policy，下面让我们来看看这个文件里都写了些什么
// 内置扩展库授权规则
// 表示 java_home/jre/lib/ext/ 目录下的类库可以全权访问任意资源
// 包含 javax.swing.*, javax.xml.*, javax.crypto.* 等等
grant codebase file:${{java.ext.dirs}}/* {
 permission java.security.allpermission;
};
// 其它类库授权规则
grant {
 // 允许线程调用自己的 stop 方法自杀
 permission java.lang.runtimepermission stopthread;
 // 允许程序监听 localhost 的随机可用端口，不允许随意订制端口
 permission java.net.socketpermission localhost:0, listen;
 // 限制获取系统属性，下面一系列的配置都是只允许读部分内置属性
 permission java.util.propertypermission java.version, read;
 permission java.util.propertypermission java.vendor, read;
 permission java.util.propertypermission java.vendor.url, read;
 permission java.util.propertypermission java.class.version, read;
 permission java.util.propertypermission os.name, read;
 permission java.util.propertypermission os.version, read;
 permission java.util.propertypermission os.arch, read;
 permission java.util.propertypermission file.separator, read;
 permission java.util.propertypermission path.separator, read;
 permission java.util.propertypermission line.separator, read;
 permission java.util.propertypermission java.specification.version, read;
 permission java.util.propertypermission java.specification.vendor, read;
 permission java.util.propertypermission java.specification.name, read;
 permission java.util.propertypermission java.vm.specification.version, read;
 permission java.util.propertypermission java.vm.specification.vendor, read;
 permission java.util.propertypermission java.vm.specification.name, read;
 permission java.util.propertypermission java.vm.version, read;
 permission java.util.propertypermission java.vm.vendor, read;
 permission java.util.propertypermission java.vm.name, read;
};

grant 如果提供了 codebase 参数就是针对具体的类库来配置权限规则，如果没有指定 codebase 就是针对所有其它类库配置的规则。
安全检查没有通过，那就会抛出 java.security.accesscontrolexception 异常。即使通过了安全检查，操作系统的权限检查也有可能失败，此时将会抛出其他类型的异常。
如果按照上面所配置的规则，使用默认安全策略的 jvm 将无法访问本地文件，因为授权规则使用的是白名单。如果需要访问本地文件，可以增加下面的规则
permission java.io.filepermission /etc/passwd, read;
permission java.io.filepermission /etc/shadow, read,write;
permission java.io.filepermission /xyz, read,write,delete;
// 允许读所有文件
permission java.io.filepermission *, read;

permission 的配置参数正好对应了它的构造器参数
public filepermission(string path, string actions) {
  super(path);
  init(getmask(actions));
}

java 默认安全规则分为几大模块，每个模块都有各自的配置参数
其中 allpermission 表示打开所有权限。还有一个不速之客 hibernatepermission，它并不是内置的权限模块，它是 hibernate 框架为自己订制的，这意味着安全规则是支持自定义扩展的。要扩展很容易，只需编写一个 permission 子类，并实现其四个抽象方法。
abstract class permission {
  // 权限名称，对于文件来说就是文件名，对于套接字来说就是套接字地址
  // 它的意义是子类可定制的
  private string name;
  // 当前权限对象是否隐含了 other 权限
  // 比如 allpermission 的这个方法总是返回 true
  public abstract boolean implies(permission other);
  // equals 和 hashcode 用于权限比较
  public abstract boolean equals(object obj);
  public abstract int hashcode();
  // 权限选项 read,write,xxx
  public abstract string getactions();
}
class custompermission extends permission {
  private string actions;
  custompermission(string name, string actions) {
    super(name)
    this.actions = actions;
  }
  ...
}

jvm 启动时会将 profile 里面定义的权限规则加载到权限池中，用户程序在特定的 api 方法里使用权限池来判断是否包含调用这个 api 的权限，最终会落实到调用权限池中每一个权限对象的 implies 方法来判断是否具备指定权限。
class customapi {
  public void somemethod() {
    securitymanager sec = system.getsecuritymanager();
    if(sec != null) {
      sec.checkpermission(new custompermission(xname, xactions));
    }
    ...
  }
}

启用安全检查，将会降低程序的执行效率，如果 profile 里面定义的权限规则特别多，那么检查效率就会很慢，使用时注意安全检查要省着点使用。
沙箱的安全检查点非常多，下面列举一些常见的场景
文件操作
套接字操作
线程和线程组
类加载器控制
反射控制
线程堆栈信息获取
网络代理控制
cookie 读写控制
如果你的服务端程序开启了安全检查，就需要在 policy 配置文件里打开很多安全设置，非常繁琐，而且配置多了，检查的性能也会产生一定损耗。这点有点类似 android 的应用权限设置，在每个 android 应用的配置文件里都需要罗列出一系列应用子权限。不过用 java 来编写服务端程序似乎开启安全检查没有任何必要。
以上就是java应用程序的安全沙箱机制是什么的详细内容。