目      录

简介... 1

BEA WebLogic JRockit的性能、可管理性、简单性... 2

BEA WebLogic JRockit JVM的体系结构... 3

企业应用开发和部署的简单方法... 3

提高开发人员的生产率... 3

逐步优化运行时效率... 4

“零开销”监控... 4

动态优化代码产生器... 4

高效的线程管理... 5

以可伸缩性和可靠性为目的的自适应内存管理... 5

自适应堆管理... 5

自动垃圾收集... 6

优化客户端和服务器环境的内存管理... 7

企业性能、可伸缩性和可靠性的管理... 8

BEA WebLogic JRockit 监控和管理API 8

BEA WebLogic JRockit 管理控制台... 8

BEA WebLogic JRockit 运行时分析器... 9

BEA WegLogic JRockit的性能和可伸缩性... 9

总结：简单出众的企业Java. 10

如何获得... 10

关于BEA.. 11

现在的开发人员已经目睹了大规模系统开发的蓬勃发展，其认识远远超越了三十年前对后台办公系统（back-office）和大型机系统发展的认识限制。Java程序设计语言已经成为创建大规模企业系统的一个关键因素。它已经从一种“一次编写、到处运行”的客户端语言发展成为开发大规模企业应用所选择的语言。Java“构建模块”这一特性已经帮助降低了应用开发的时间和复杂度。

但是目前不断增长的用户数量和持续增加的复杂业务需求把Java应用推向了它们的极限，为了获得并维持企业Java应用的性能、可伸缩性和可靠性，公司通常不得不花费大量的开发时间和资源。硬件厂商针对它们自己独特的体系结构优化了许多Java虚拟机（Java Virtual Machine，JVM），因此使得在花费较大硬件投资的前提下，基本的性能可以得到保证。为了满足用户、业务和财政要求，开发人员需要用一种简单、划算的方式来确保应用程序的性能、可靠性以及低成本、基于标准的平台的可伸缩性。

BEA WebLogic JRockit是唯一一种专门为简化大规模整体企业环境下的Java应用开发和管理任务而设计的Java虚拟机。使用BEA WebLogic JRockit，开发人员在开发高性能、可伸缩性和可靠性的应用程序时，无需了解Java虚拟机的内部机制。BEA WebLogic JRockit通过快速的启动性能加快了应用程序的开发效率。它利用逐步优化的特性提供了即取即用的应用程序的性能和可靠性，这种特性不需要大量的手工配置和调节就可以使JVM自动提供可能达到到的最佳应用程序性能。独特的可管理特性给开发人员提供了一种实时的可见性和控制能力，在负担大量用户和事务的情况下，向健壮的行业系统交付稳定性和可靠性的同时能确保最高的应用程序性能和可用状态。而且BEA WebLogic JRockit也是唯一一个使得开放的基于Intel标准的平台达到最高性能而设计的Java虚拟机，这可以向企业Java应用程序交付最佳的性价比和最低的总拥有成本。

每一个BEA WebLogic JRockit JVM的子系统的设计，都为大规模的、整个企业部署中的应用程序交付了卓越的性能、简单性和可管理性。

l        代码生成子系统在整个应用程序的生存期内进行逐步优化。

l  对线程管理进行优化，将线程之间的同步减到最少。

l        内存管理的设计目标是：高效的内存使用率和程序运行过程中的吞吐量。

l        Java模型保持了系统元数据的最新视图。BEA WebLogic JRockit JVM用高度优化的算法有效地管理类、段和方法，以及Java应用的类加载和字符串处理。Java模型还具有许多优化的性能，可确保采用Java反射访问各种实例成员的效率。

l        I/O子系统针对普通Java文件和网络I/O行为进行了适当的调整和优化。

外部管理和监控API可帮助开发人员进行性能调整并确保系统正常，它们还通过集成第三方工具提供可扩展性。

图 1 BEA WebLogic JRockit的体系结构

设法理解和优化企业应用程序的运行时行为时，开发人员也许要花大量的时间和精力，而JVM最终决定了运行时性能，并可以实时影响应用程序的行为。它还可以为开发人员提供传统工具中不明显的洞察力和优化选项。

BEA WebLogic JRockit JVM减少了开发人员在获得Java应用程序的性能时所面临的大量时间和精力以及众多的绊脚石。BEA WebLogic JRockit是唯一设计成允许开发人员在无需调整单个配置参数的情况下即可实现应用程序性能优化和可伸缩性的JVM。它通过逐步优化和自适应内存管理达到这个目的，借此方法，JVM可基于应用程序本身的运行条件和底层环境（客户端和者服务器系统、并发用户和内存要求、以及各种形式的系统资源，例如可用的内存和CPU）自动调整它自己的行为，从而交付贯穿应用程序生存期的最佳性能、可伸缩性和可靠性。

应用程序开发包括应用程序的反复重新部署，也就是开发人员编写、调试、改进代码的过程。除开发工具之外，能够有助于开发人员提高生产率的一个最重要因素就是构建、部署和起动应用程序所花费的时间。

即使编译的代码执行得更快，但某些JVM还是通过在运行时解释Java代码将启动时间最小化。BEA WebLogic JRockit在第一次使用方法时，对每个方法都要进行“即时”（just in time，JIT）编译，然后将编译后的方法缓存到磁盘上以便随后重用，从而平衡了启动时间和运行时性能。据此，随后对应用程序的部署或者重新启动可自动从磁盘检索编译好的代码，这就缩短了启动时间并提高了整体性能。获得优化的应用程序性能，通常是Java开发工作中的一个重要部分。因此，BEA WebLogic JRockit既可通过所有方法的JIT编译交付快速的运行时性能，也可通过已编译方法的代码缓冲交付快速的启动时间，从而显著提高了全体开发人员的生产率。代码缓冲已经作为一个试验性的特色被引入，并将不断增强。如图2所示，BEA WebLogic JRockit JVM在第一次遇到方法时，要对每个方法进行编译并缓存。

图2 方法的JIT编译随时间的曲线

BEA WebLogic JRockit JVM通过逐步优化将已编译代码的运行速度和自适应性能技术的优点有机的结合起来。逐步优化是一个从部属开始、贯穿整个应用程序生存期的不断对性能进行改进的过程。JVM会编译第一次遇到的每一个方法，生成特定于平台优化的机器码，例如IA64体系结构独有的快速寄存器分配。然后，JVM在运行并确定应用程序将大部分时间花费在哪些方法上的同时，还要监控应用程序的运行，以备更好的优化。这种方法排除了一个正在运行的应用程序在生存期之初的许多性能瓶颈。

BEA WebLogic JRockit动态运行时环境使用了一个复杂的、低开销的基于采样方法的技术来确定要优化的区域。一个“采样器线程”按周期性的时间间隔唤醒并检查多个应用程序线程的状态。它确定每一个线程所执行的功能，并记下一些运行历史记录。跟踪这些信息，就可知道应用程序将大部分时间花费在哪些方法上，并指定这些方法进行优化。监控的开销一般只有1－2％。

在应用程序部署初期，BEA WebLogic JRockit监控应用程序的执行以确定代码优化的区域。当运行时性能提高并稳定之后，JVM监控的频率会越来越低，开销也会进一步减到最少，并由此，将性能最大化。如果添加或更改了方法、或者改变了应用程序的使用，都会导致应用程序在不同的方法上花费更多时间，BEA WebLogic JRockit进一步优化了这些方法，并再次进行监控直到它们的性能稳定为止。

BEA WebLogic JRockit的动态优化编译器使用了许多技术来提高那些频繁使用的方法的性能。一些Java开发人员认为，由于Java“开放性”的特性，例如动态类型强制转换和虚拟方法调用，使得JIT编译并不能有效地优化Java。然而，JRockit的逐步优化克服了这一问题。在第一次调用方法时，方法由JIT编译并生成有效的代码。然后，使用运行时监控和动态优化并根据收集到的运行时信息来进一步提升性能。

最常用的方法是以侵略性优化方式进行重新编译并动态替换。由于方法的数目越来越小，范围对代码调度程序非常重要，因此可使用嵌入式的方法来准备代码以便进一步优化。然而，这种方法可能存在疑问，因为Java中存在某些调用的运行时鉴定，BEA WebLogic JRockit使用令人满意的直观推断来确保嵌入式方法提供实质性的性能提升。

如图3所示，应用程序通常要将99％的执行时间花费在10％的方法上。 BEA WebLogic Jrocki JVM 监控每个方法的执行时间，并对经常使用的方法进行贪婪优化。即便运行时行为在应用程序的生存期内有所改变，JVM 也会识别需要优化的新方法，并动态优化它们以便不断提高性能。

图3 方法的逐步优化随时间的曲线

动态代码优化不但可以提升应用程序在时间上的性能，还可以优化不同使用模型的性能。例如，一个应用系统在改变使用模型时，可能在某天或某月内有不同的需求。动态优化方法可确保在最后阶段突然成为性能瓶颈的方法也得到优化。

BEA WebLogic JRockit中的对象分配同样由代码产生器负责。对于小对象而言，分配是本地线程，这意味着每个分配的Java线程都有一个用于保留对象的指定区域。因此，同步（等待锁）不会浪费时间。对于优化的代码，小对象的分配是嵌入式的。大对象的分配通常只用于大数组或者大小不定的数组。

BEA WebLogic JRockit的线程管理部分负责管理锁和等待原语的实现。锁用于实现Java中的同步关键字。在BEA WebLogic JRockit中有两种锁：瘦锁和胖锁。

瘦锁用在没有竞争的地方。瘦锁的加锁和解锁是一个非常快的操作。对于单CPU系统而言，锁是通过减少多处理器系统所需的额外锁原语来进一步优化的。

如果在一个瘦锁上的竞争长于x（其中x是一个毫秒级的变量并且依赖于硬件）时长，那么该瘦锁就会变成一个胖锁。虽然胖锁的加锁和解锁操作要比瘦锁慢，但仍然是很快的。在多处理器系统上，BEA WebLogic JRocki使用了一个特殊的旋转锁程序，通过使加锁的锁在休眠之前旋转一小会儿来提高胖锁的性能。由于持有该锁的线程可能运行在另外一个CPU上，而且通常会在最初的旋转周期内释放该锁，因此这种方法可使不必要的休眠期间减少数千个CPU周期。

Java中的内存管理可能导致大的性能问题，尤其是在企业环境中负担大量用户和事务时。但是它也为性能优化提供了极大的机会。BEA WebLogic JRockit应用了许多机制，通过自动调整内存管理以满足应用程序行为和运行时环境，来提升性能、可伸缩性和可靠性。

用户通常要在同一个系统上同步运行多个应用程序实例，在这样的企业环境中，堆管理问题尤其重要。根据JVM定义其堆大小的方式，在某些情况下，JVM的新实例可能没有足够的内存来维持令人满意的性能。

BEA WebLogic JRockit JVM专门设计用于在解决整个系统内存使用时，维持应用程序的性能。每个BEA WebLogic JRockit JVM监控它自己的内存利用率，并根据其应用程序的需求动态地增大或者减小堆的大小。例如，一个销售处理应用程序在营业阶段可能需要较多内存，因此它会在这些时间增大它的堆，而在非营业时间释放堆。然而，一个电子商务应用程序可能在处于使用高峰期的某天的某个时间段内，捕获额外的内存，然后在低峰期释放这些内存。

如图4所示，BEA WebLogic JRockit自动调整堆的大小以满足变化的条件和应用程序要求。

图4  自适应堆管理

在Java应用程序性能中，垃圾收集（回收对象不再引用的内存）是一个重要的因素。内存的有效使用可提升应用程序的性能和可伸缩性。另一方面，不当的垃圾收集方法会打乱应用程序的执行，并严重降低整个系统的性能和可靠性。一些应用程序要求最高的可能应用程序吞吐量，并可允许周期性的垃圾收集暂停；而其他的应用程序则需要连贯性，为了将暂停时间最小化，可以牺牲少许吞吐量。

BEA WebLogic JRockit的内存管理系统提供了一组为不同类型应用程序和环境量身定做的垃圾收集策略，以及一个自适应模型，它利用运行时分析来动态地调整垃圾收集策略，以最好地适合应用程序的性能和行为要求。

BEA WebLogic JRockit的垃圾收集系统使用以下方法的各种组合形式在垃圾收集期间产生较好的运行时效率：

并行垃圾收集 通过利用多CPU计算机的优势来加快垃圾收集速度的方式，优化应用程序的吞吐量。当所有可用的CPU都被垃圾收集器使用以回收死亡（未引用的）对象占用的内存时，应用程序将会暂时中止处理。

代（Generational）垃圾收集 保持最近分配的对象处于“托管”状态，直到它们存在了一段确定的时间为止。垃圾收集器周期性地扫描托管区，删除死亡对象并提升活跃对象脱离托管状态，将其放入长期使用的对象空间。这种方法增加了由垃圾收集导致的暂停次数，但是由于为内存区域执行的最频繁的垃圾收集动作比整个Java堆小的多，因此通常情况下，平均暂停时间和总暂停时间会显著降低。

单空间（非代 non-generational）垃圾收集 把Java堆配置成一个单独的、用于分配所有对象的连续空间。由于在每个垃圾收集周期内，需要遍历整个Java堆以清除死亡对象，因此相对于代垃圾收集，这种方法可产生较少的暂停次数，但暂停时间较长。

并发垃圾收集 在一个后台进程中进行内存回收，这会稍微降低应用程序的吞吐量。然而，由于不像并行垃圾收集器在收集周期内会中止所有应用程序的线程，并发垃圾收集器在后台处理部分垃圾收集，且不会为了整个垃圾收集周期而阻塞应用程序的线程，因此会使垃圾收集的次数大大减少，暂停次数也更少，暂停时间也更短。并发垃圾收集器可在应用程序继续在其他CPU上运行的同时，在一个或者多个CPU上用后台方式收集垃圾。

这些方法的变化为一系列的应用程序和环境提供了最有效的垃圾收集方式。例如，如图5所示，随着工作量的增加，相对于并发收集策略而言，并行垃圾收集策略提供了较高的应用程序吞吐量。然而，由于在垃圾收集过程中应用程序处于挂起状态的同时，有较多的死亡对象需要收集，因此并行收集策略会导致更高的暂停时间。

如果应用程序有足够使用的堆，并且需要将暂停时间最小化，并发垃圾收集是一个不错的选择。图5展示了并发垃圾收集器是如何将暂停时间保持到最小的。与并行模式相反，并发垃圾收集的暂停时间不是随着堆的大小而增长的，而是依赖于堆中活跃数据的数量，因此并发垃圾收集特别适合处理非常大的堆。因为并发垃圾收集器可在应用程序继续在其他CPU上运行的同时，用后台方式在一个或者多个CPU上收集垃圾，从而将垃圾收集的次数以及对应的暂停时间减到最少，因此并发垃圾收集器也非常适合面向批处理的、运行在多个CPU计算机上的单线程应用程序。在这种情况下，对于应用程序而言，垃圾回收实际上变成了免费的开销。

随着工作量的增加，并行垃圾收集增加了吞吐量，但是也增加了暂停时间。另一方面，并发垃圾回收将暂停时间减到最少，但是相对于并发垃圾收集，它的吞吐量要稍微小一些。

图5  并行垃圾收集与并发垃圾收集的比较

图6 代垃圾收集与单空间垃圾收集的比较

单空间（非代）的并行垃圾收集适合于创建了许多长寿命对象的应用程序，因为垃圾收集很少发生且一般都发生在后台。图6展示了在堆使用相当频繁的应用程序中，单空间垃圾收集如何将暂停次数减到最少。

对具有很多短寿命对象的应用程序而言，图6展示了代收集模型不但可导致非常频繁的垃圾收集，还可在保持暂停次数尽可能少的情况下帮助堆的使用率保持在范围之内。

图6中的曲线中，红线表示内存的使用率，蓝线表示垃圾收集的暂停次数。代垃圾收集导致了较少的全堆收集。代垃圾收集可用于那些具有许多短寿命数据的应用程序中。单空间（非代）垃圾收集则应该用于具有许多长寿命对象的应用程序中。

由于应用程序的行为在运行时可随时间变化，所以为指定的应用程序选择最好的垃圾收集方式是比较复杂的。BEA WebLogic JRockit允许开发人员或者系统管理员选择自适应的垃圾收集模型，从而减少了这种复杂性。事实上BEA WebLogic JRockit是惟一具有自适应垃圾收集器的JVM，它在运行时期间实际转换垃圾收集策略，并自动选择垃圾收集算法以便最好地与当前运行的程序程序相匹配。开发人员为特定的应用程序（最小暂停次数或者最高吞吐量）指定最重要的行为，自适应垃圾收集器可自动配置它本身以提供这些特征。如果应用程序当前（或者临时）需要一个托管区，自适应垃圾收集器将会识别这一需求并创建一个托管区。如果应用程序的垃圾收集暂停时间变得太长，自适应垃圾收集器将会调节垃圾收集算法以防止长暂停。

图7 自适应垃圾收集

在图7上部的曲线中，通过在单空间策略和带有托管区的代堆中的切换，垃圾收集器系统修改其算法以便为正在运行的应用程序获得最少的暂停次数。在表示期望最大吞吐量的下部曲线中，垃圾收集系统从具有托管区的代堆向可以提供最大吞吐量的单空间算法转变。

BEA WebLogic JRockit JVM这种独一无二的特性简化了开发人员的任务，并使应用程序在最小的可能暂停时间和最大的可能吞吐量（回收已用内存的能力）之间达到最佳平衡。开发人员无需为达到预期的性能而花费大量的时间和精力来配置和调节JVM。

为了达到最佳的应用程序性能，应用程序为其分配适当数量的起始内存是很重要的。太小的堆会导致内存不足的错误。太大的堆则可能导致长时间的垃圾收集暂停，或者由于其他应用程序急需内存而降低整个系统的性能。

BEA WebLogic JRockit允许开发人员在客户端开发或服务器环境中设置初始的内存分配，以获得最佳的性能。缺省状态下，BEA WebLogic JRockit会为服务器环境配置自己堆的大小和托管区的大小，并按照系统中CPU的数量和总系统的RAM自动调整堆和托管区的大小。如果开发人员或者系统管理员以“-client” 选项启动JVM，BEA WebLogic JRockit 会为浏览器中的Java applet或单用户的Swing应用程序最佳地配置自己堆的大小和托管区的大小，而此单用户的Swing应用程序运行在至少有128M系统内存的单-CPU PC上。因此在客户端开发模型中，JVM会以较小的堆和对垃圾收集器敏感的暂停时间开始。

JVM对处于运行时的应用程序行为有着重要的影响，但是Java开发人员看到了应用程序性能的商业前景及其最终的任务。使用 BEA WebLogic JRockit独特的性能管理工具，JVM不再是一个“黑盒子”。BEA WebLogic JRockit 管理控制台、运行时分析器以及监控与管理API，为开发人员和系统管理员提供一种空前水平的实时可见性和控制能力，使得他们能够调整应用程序的性能，并在改变使用模式和业务条件的过程中确保系统正常。

BEA WebLogic JRockit 提供了一种独特的能力：在不引入明显影响系统性能和操作开销的情况下，监控和管理JVM和处于运行时的Java应用程序活动。 BEA WebLogic JRockit 监控和管理API为应用程序及多个外部应用程序管理工具提供了一种一致且没有争议的方式，以便在不具备解读应用程序字节码的情况下，与JVM打交道并收集应用程序的运行时信息。

这些API允许在运行时用手工和（或）程序的方法进行数据收集。在其他功能中，监控API可为以下功能提供数据收集：

1： 监控和诊断方法层的应用程序运行条件。这些API测量被监控方法的频率和花费在该方法中的时间。它们也可以监控意外情况。

2：监控JVM的运行条件，例如垃圾收集模型和堆的使用率。

3：监控操作系统和硬件运行条件，例如可使用的内存和CPU利用率。

这些管理API允许应用程序或者外部工具可以手工或者以程序方式修改应用程序或JVM的运行时特征。在其他功能中，管理API提供了以下能力：

1：不需要重新启动JVM，就可以修改JVM的运行条件，例如堆的大小、GC参数和CPU绑定。

2：修改应用程序的方法，例如forceCompilation。

3：监控垃圾收集事件，以便确定有过长时间趋向的垃圾GC时间。

4：收集线程和帧的完整信息。

BEA WebLogic JRockit管理控制台（JMC） 利用底层的BEA WebLogic JRockit 监控和管理API，为开发人员和系统管理员提供了对内部工作和网络间多个JVM实例的行为的实时可见性和控制能力。BEA WebLogic JRockit 是唯一一种能够提供这种水平的可管理性和应用程序可见性的JVM。特别是它能够提供最新的信息，这些信息包括CPU利用率、GC暂停时间、堆利用率、线程的个数和状态，以及运行时行为，如花费在个别方法上的时间。线程堆栈的转储也可以通过控制台来捕获。BEA WebLogic JRockit管理控制台为诸如垃圾送收集参数的运行时行为提供了实际控制。 基于规则的警报、异常通知和边界条件通知（例如过高的堆利用率）可以帮助开发人员和系统管理员确定并理解应用程序的行为问题，并在发生灾难性失败之前纠正它们。

如图8所示，BEA WebLogic JRockit管理控制台对JVM和运行时的应用程序行为提供了可见性和控制能力。

在其他的功能中，BEA WebLogic JRockit管理控制台还提供以下能力：

1：为离线分析永久保存监控得数据。

2：能够根据控制台内设置的通知规则，通过程序触发外部应用程序中对Java类的调用。

图8  BEA WebLogic JRockit管理控制台

BEA WebLogic JRockit运行时分析器利用BEA WebLogic JRockit内置的监控框架帮助开发人员在产品环境中对应用程序的行为进行查看和分析。在离线环境中，开发人员可以用BEA WebLogic JRockit收集的信息来分析应用程序的运行时行为，诊断潜在的与性能相关的情况。

图9表示了BEA WebLogic JRockit运行期分析器是如何帮助开发人员查看并分析应用程序的运行时行为的。

图9  BEA WebLogic JRockit运行时分析器

BEA WegLogic JRockit JVM的性能和可扩展性在行业内处于领先位置。它的逐步优化机制提供了持续不断的性能提升，而自适应内存管理确保了高的运行时效率和部署的简单性。内置的监控使JVM可以把自己的性能发挥到极致，运行时管理工具使得开发人员可以通过改变业务条件和应用程序工作量对性能进行微调。

除了这些特点之外，BEA WegLogic JRockit还针对用工业标准的基于Intel的服务器所搭建的系统进行了性能优化，包括了从32位基于Intel Xeon处理器的系统到采用最新的64位Intel Itanium 2处理器的服务器。BEA WegLogic JRockit是市场上在IA32平台运行最快的JVM，也是唯一可以用在IA64平台上的JVM。由于开发了这种体系结构，并已鉴定它100％地符合Java2的标准规范，因此在硬件、操作系统和中间件提供商的选择上具有了较大的灵活性。这种基于标准的优化使得公司在降低组件和运行成本地同时，可快速定标他们的企业的应用程序的基础结构。

当使用诸如BEA WegLogic JRockit的高性能JVM将应用程序部署在基于Intel Itanium 2处理器的平台上时，Java编程语言就成为大规模、服务器端和企业类应用程序的最终部署平台。这些应用程序通常要求大的数据集，利用大量的可用内存来减少磁盘交换所花费的时间，从而发挥64位计算的真正优势。BEA WegLogic JRockit在64位平台上能够利用大内存空间的能力也可以帮助公司用较低的代价和较高的效率来定标他们的企业应用程序，以满足未来的需要。

通过标准的基准测试，BEA WegLogic JRockit不断的表现出卓越的应用性能和性价比。

SPECjbb2000

SPECjbb2000 是一个用于评估服务器端JVM性能的工业标准的测试基准。 标准性能评估协会（SPEC） 为了测量多CPU服务器上JVM性能的可伸缩性，创建了这个基准。BEA WebLogic JRockit 设计具有跨多个CPU进行线性定标的能力，结果表明，这个基准在CPU可伸缩性方面的性能要优于其他的JVM。有关该测试基准的更多信息可以从标准性能评估协会（SPEC）的web站点上获得（http://www.spec.org）。

SPECjAppServer2002

SPECjAppServer2002 是一个企业JavaBeans测试基准，它用来测量J2EE应用服务器和容器的可伸缩性和性能。由于所有的J2EE服务器都运行在JVM上，因此在测量应用服务器的同时隐含地测量了JVM。在大型服务器上，BEA WebLogic JRockit表现出了超乎想象的高性能和可伸缩性。 有关测试基准的更多信息可以从标准性能评估协会（SPEC）的web网站上获得（http://www.spec.org）。

对企业应用而言，BEA WebLogic JRockit 简直就是最好的JVM。它给Java开发人员从开发开始到整个Java应用程序生存期内改善性能提供了一种直观而且简单的方式。它独一无二的特点，包括逐步优化、自适应性能技术和运行时的可管理性，为企业Java应用程序所需要的速度、事务容量、可伸缩性和可靠性提供了保证，同时，对工业标准平台的优化可以减小企业系统的成本。采用BEA WebLogic JRockit，开发人员可以在规划应用程序运行方式中节省大量时间，而将时间主要用于确定业务的运行。

BEA WebLogic JRockit JVM作为一部分包含在了BEA WebLogicEnterprise Platform^TM和BEA WebLogic Sever^TM中。另外，也可在http://commerce.bea.com/index.jsp下载适用于下列Intel体系结构平台环境的BEA WebLogic JRockit JVM：

1 Microsoft Windows （IA32和IA64）

2 Red Hat Enterprise Linux（IA32和IA64）

3 SuSE Linux ES （IA32和IA64）

关于支持的最新平台，请参考http://edocs.bea.com。a