IBM多租户JVM（Multitenant JVM）目前随着IBM JAVA 8
beta版已经发布。通过在一个多租户JVM上运行多个应用程序，云系统可以加速应用系统的启动时间、减少应用系统内存消耗。主要开发者Graeme
Johnson和Michael Dawson撰文介绍了多租户云系统JVM背后的技术，并讨论了主要成本以及其带来的收益。
文章首先介绍了多租户JVM诞生的背景：
对于运行系统、提供服务所需的基础设施，云供应商必须权衡其成本消耗及其可带来的收益。这种利弊权衡迫使供应商寻找多种系统架构。云供应商目前可从
无共享架构到多用户共享架构范围内进行选择。无共享架构中，供应商提供面向单一用户的软件、硬件及应用程序。多用户共享架构中，多个用户共同使用供应商提
供的同一款应用软件，并共享底层软件、硬件。
选择框架主要需要权衡密集度(density)
与隔离性(isolation)。密集度指特定软硬件可提供的系统和服务的数目。共享度越高，密集度就越高。密集度越高，供应商成本越低。同时，共享度的
增高将降低租户（tenants，指交付的单个系统或服务）间的隔离性。隔离性描述了单个租户对活动与其他租户数据的影响程度。
对于基于JAVA的租户，可按是否共享JVM对框架进行划分。任何共享顶层应用的框架一定共享了JVM。共享JVM既可以节省内存又可以节省处理时
间。但是在传统的JVM技术中，共享JVM将导致基础架构层失去隔离性，从而要求顶层应用提高自身隔离性以满足架构需求。本文介绍的多用户共享架构已在
IBM最新发布的JAVA 8测试版中进行实验，并且成功。这个架构具有传统共享JVM架构优点，此外还表现出优于传统共享JVM框架的隔离性。
使用多用户共享JVM最大的优点是部署可以避免多个标准JVM相关的内存消耗。这种内存消耗主要来自：
- Java堆消耗成百上千兆的内存。而且即使对象是相同的，堆对象也不能在JVM之间共享。此外，JVM还倾向于使用所有分配给他们的堆，即使它们只在在很短的时间才会用到峰值量。
- 因为生成的代码是私有的并且消耗内存，所以JIT编译器需要占用几十兆的内存。代码的生成也需要消耗大量的处理器时间，而这会使应用运行变慢。
- 类的内部结构占用内存（很多组成部分还会存在所有应用中，如String,Hashtable）。而且这些结构在每一个JVM中都会有一个实例。
- 每个JVM会给每个核分配一个默认的垃圾收集辅助线程，同时每个JVM还有多个编译线程。垃圾收集活动和编译活动可以一个或多个的JVM中同时出现，但是考虑到JVM会竞争有限的处理器时间，这种现象不是非常理想。
多租户JVM可以减少内存占用、降低处理成本，除此之外，相对于传统的在单个JVM上运行多个应用的方式，多租户JVM还可以提供了更好的隔离性。
另外一个益处来自启动时间的缩短：当第一个租户启动后，后续启动的应用将需要少于第一个的启动时间，因为JVM已经在运行了。启动时间的减少有利于运行周期短的程序的使用。而且我们在脚本处理时经常会用到这类程序。
当然，鱼和熊掌不可兼得。多租户JVM的缺点包括：
- 相比于多个应用运行在单个隔离的JVM这种传统方式，多租户JVM的主要弊端来自于隔离性的降低。例如，多租户JVM中一个原生崩溃（native crash）可以影响到所有租户。
- 为了执行JVM工作我们必须要执行多租户扩展（multitenancy extensions），这会对性能带来不好的影响。然后，这影响会随着租户数量的增加而下降——因为通过在同一个系统运行多个JVM我们可以避免处理器和内存的浪费。
接着，文章简单介绍了如何启动多租户JVM。
为了和其它租户共享运行时间，应用程序使用者需要在启动应用程序时在启动应用程序时加入一个单变量，例如：java -Xmt -jar one.jar
这样操作的结果会使应用程序好像运行在其专用的JVM一样。但实际上它和其它应用程序运行在同一个JVM中。多租户JVM扩展使以这种方式启动应用
成为可能，并且它还为共享JVM的多租户提供隔离性。当一个租户启动后，JVM启动器会选择定位在现有的共享JVM后台程序（javad）或者在必要的时
候启动，当第二个租户启动时，这个租户会找到现有的共享JVM后台程序并且用这个JVM进行运行，这样做的结果是这两个租户共同的引导程序会出现在
javad过程。这种布置使租户可以共享大部分运行时的结构。我们只需要对命令行进行有限的修改，就可以实现通过多租户共享JVM运行现有的应用程序，这
一方法很简单。
多租户JVM目前还有一些限制，主要包括：
- JNI natives——多租户共享JVM并没有给JNI native提供隔离性。因此，含有用户添加的JNI
native的应用程序在多用户共享JVM中运行并不一定稳定。这些应用程序可能会影响整个JVM的运行并获取其他租户的信息。考虑到原生代码需要足够的
“信任”（例如众所周知的中间件），这个风险可能是可以接受的。此外，操作系统只允许共享JVM进程下载一份共享库的副本，而且这个副本是原生代码的所在
地。这就导致当多个租户共享同一个库时，他们不能载入相同的原生代码。
- JVMTI（Java虚拟机工具接口）：因为调试和分析功能会影响到所有共享JVM服务器的租户，所有多租户JDK目前还不支持这些功能。这也是我们将来工作中要解决的问题。
- GUI项目：诸如SWT的库在原生层层是全局声明的，所有多租户JDK目前还不支持这些库。
| 
