如Memory Management Guide中所述，JRockit使用了thread local area (TLA)分配以避免直接从Java堆分配所有内存所带来的瓶颈。一个TLA的默认大小是2 Kb，这对于一个分配大量内存的Java程序来说太小了，尤其是在JRockit进程使用许多CPU时。此外，JRockit还经常直接从堆分配大型对象。默认情况下，大型对象被定义为大于2 kB的对象，通常是数组。这个常量对于分配大量大型数组的应用程序来说太小了，在涉及到XML时，大型数组并不罕见。

　　如果这些常量对于应用程序来说太低，那么内存分配就会成为一个瓶颈。在这种情况下，调优这些常量就会产生显著的性能提升（提升5-10%并不罕见）。

　　要查明应用程序中是否存在这种瓶颈，可以创建JRA记录并在JRA工具中加载它。记录将在General选项卡中打开，该选项卡包含有关于Allocation的区域。

　　下面是来自一个应用程序的示例条目，其中包含有-XXtlasize和-XXlargeobjectlimit的默认值。

使用JVM命令行-Xms2g -Xmx2g的结果

　　该记录的生成花费了2分钟，在此期间，分配了220万个TLA和80万个大型对象。这意味着堆锁定几乎达到了20万次/秒。虽然这似乎还处于合理的限制范围内，但是让我们增大TLA大小和大型对象限制，然后看看会有什么结果。

使用JVM命令行-Xms2g -Xmx2g -XXtlasize64k -XXlargeobjectlimit8k的结果

　　现在我们获得了6千次/秒的堆锁定，大约是原来的三十分之一。在这个例子中，这仅仅使性能提高了1%左右。这几乎没什么大的影响，但是已足以说明这种思路。此外，在此例中，我还可以对tlasize和largeobjectlimit使用更小的值而获得相同的性能提升。在第一幅屏幕快照中，大型对象的最大大小是2 kB，所以将largeobjectlimit设置为3 kB就已经足够了。

　　另一个信息源是JRA工具中的Lock Profiling选项卡。使用最近的几个JRockit版本生成的JRA记录包含关于Native lock即JVM内部锁的数据。其中的一个琐是GC:Heap锁，JRA展示了在记录期间竞争该锁的次数。如果数值很大，则表明堆锁定已经成为瓶颈，就需要对tlasize和largeobjectlimit的值进行调优。

　　警告：将这些值设置得过高会提高对垃圾收集的需求，因为小于这些值的空闲内存区域如果不进行压缩（即在垃圾收集过程中对堆进行碎片整理）就无法使用。

　　这些常量的默认值很久以前就已经设定了，而且多年来也都是合理的值。然而，随着更快的CPU和多核芯片的出现，对这些参数进行调优的需求日益增加。我们正寻求在未来的JRockit版本中提供更好的开箱即用设置并/或对其进行动态控制，但是同时这些设置也是进行手动调优的不错的例子。

原文出处:http://dev2dev.bea.com/blog/hstahl/archive/2006/06/running_jrockit.html