前言

这一周因为一直在赶自己的项目，没怎么继续更新，主要是在自己的CSDN博客上更新一些自己项目中的问题解决方案，因为跟业务比较靠边，头条还是偏娱乐的，如果感兴趣的可以去我饿CSDN博客上关注一下，下面说正事，今天继续介绍我们的虚拟机。

正文

安全管理器和Java API

Java 安全模型的前三个部分——类装载器，class文件校验器以及Java自身的安全特性斜前面已经介绍完了，没看过的小伙伴可以去前面看一下，这三点都是为了保持Java虚拟机的实例和它正在运行的应用程序的正确性，使得不会被恶意下载的或者有漏洞的代码侵犯。

我们今天提到的安全管理器是一个单独的对象，在运行的Java虚拟机中，它在对于外部的资源访问控制中起到了中枢的作用。

安全管理器定义了沙箱的外部边界，它属于可定制的，所以允许为程序建立自定义的安全策略，当Java API进行任何不安全的操作时，它都会向安全管理器请求许可，从而强制执行自定义的安全策略，要向安全管理器请求许可，Java API将会调用安全管理器对象的“check”方法，这些方法的实现定义了应用程序的定制安全策略。

Java API在进行一个可能不安全的操作前，总是检查安全管理器，所以API不会再安全管理器建立的安全策略之外做事，安全管理器禁止的事,API就执行不了。

当Java应用程序启动时，它是没有安全管理器的，应用程序需要自己调用方法来启动安全管理器，如果没有安装安全管理器，那么就不会对API作出限制。

一般来说，一个受检查的动作被禁止，安全管理器的“check”方法将会抛出异常，如果这个动作被允许，则简单的返回。，当一个Java API即将执行一个潜在的不安全的动作时，它将会遵循以下两个步骤，首先看有没有安装安全管理器，如果没有，则跳过继续执行这个安全的动作，否则，它将会调用安全管理器中的“check”方法，如果操作被禁止，那么API久立即停止这个不安全的动作，如果被允许，那么这个“check”方法将简单的返回，API继续执行这个方法。

虽然安全管理器的可配置性是Java安全模型的最大优点之一，但它也是一个潜在的弱点，编写一个安全管理器是一项复杂的任务，并且可能导致错误，在实现安全管理器的check方法时，任何错误都将编程运行时的安全漏洞，所以。Java虚拟机在后来提供了一个默认的安全管理器，用户的应用程序可以显式的实例化并安装这个安全管理器，或者让他自动安装。