多处理器平台上J2EE应用的内存争用

核心提示：随着在企业级环境对高可扩展性J2EE应用的需求，需要在多处理器平台上执行线程的并行处理，多处理器平台上J2EE应用的内存争用，在JVM堆中对线程处理所需要的内存和并发处理已经成为这些J2EE应用在部署时的性能和可扩展性的瓶颈，这篇文章探讨了J2EE应用在多处理器平台上访问JVM堆中的内存的线程同步问题，我们还观察到这些

　　随着在企业级环境对高可扩展性J2EE应用的需求，需要在多处理器平台上执行线程的并行处理。在JVM堆中对线程处理所需要的内存和并发处理已经成为这些J2EE应用在部署时的性能和可扩展性的瓶颈。这篇文章探讨了J2EE应用在多处理器平台上访问JVM堆中的内存的线程同步问题。
　　
　　J2EE应用的内存需求
　　
　　当前布署在企业级环境中的J2EE应用都需要在一秒中能够处理成千上万的用户请求。这种来自大量并发用户的数据请求就产生了更大堆空间的需求，也就需要更多的内存。有了更多的内存就可以提供更大的J2EE应用堆空间，而多处理器可以处理更多的并发线程，因而现在线程访问内存的方式和访问所花费的时间就成了瓶颈所在。
　　
　　多处理器平台
　　
　　处理器数目的增加可以提高可扩展性，但同时需要处理更多的线程。线程在处理数据、创建java对象及其他Java操作时都有需要耗用内存。由于多个线程在多个处理器中运行，就需要保证在系统中数据的一致性和完整性。在处理器中的线程同时读写内存，这就需要同步这些线程来防止读写错误的数据。在图1中，显示单处理器与多处理器在访问内存时的异同。在单处理器平台中，在任何给定的时间只有一个线程被执行，因此不需要同步。然而在多处理器平台，同一时间可能会有多个线程被执行，这就需要同步访问内存来保证数据的正确性，而这就会导致争用和瓶颈?
　　
　
　　Figure 1. Single-PRocessor versus multi-processor platforms accessing memory
　　“线程本地堆”尝试通过为每一个线程在JVM堆中预分配一小块内存来解决这个问题。然而这种方式下内存空间对高内存需求的J2EE应用来说是不够的。
　　
　　实验和观察
　　
　　我们会在一个8CPU平台上为J2EE应用做一项实验，下面是实验的代码：
　　
　　String mem = request.getParameter("memory");
　　if (mem != null && !mem.equals("")) {
　　　int mem_kbytes = Integer.parseInt(mem);
　　　byte[] i = new byte[mem_kbytes*1024];
　　}
　　在每一次测试中，这些J2EE线程会请求创建一个特定内存大小的对象。在一个多用户负载测试中，我们观察到下列的数据：响应时间、吞吐量和资源利用率。
　　
　　我们将JVM堆大小设置为一个较大的值这样就可以减少垃圾回收的次数。我们注重到即使负载增加，“垃圾回收暂停时间”与“运行总时间”的比率始终在1：35左右，因此我们认为他在这项实验中的影响较小。结果如下图2。


　
　　Figure 2. Results of shared memory access on multi-processor platform

这个实验的环境如下：

　　1、应用服务器：WebLogic7

　　2、JVM：Sun JVM 1.3

　　3、操作系统：windows 2000高级服务器版

　　4、硬件：Intel Dell PowerEdge 8450 (8Intel Xeon 800MHz 处理器, 4GB RAM)

　　5、网络：100Mbps Cisco网络

　　6、负载测试工具：WebLoad
　　
　　我们观察到在增加特定内存大小的对象的负载时，吞吐量增加的比率与CPU利率的增加比较并不相同。当然，响应时间的增加也不是线性的。这些实验清楚地显示了这些J2EE线程的高内存需求导致系统内的争用并且成为J2EE可扩展性的瓶颈。我们还观察到这些线程访问内存和创建对象所花费的时间随着处理利用率的增加而增加。这可以从负载的增加导致服务请求的增加中看出来，如图3中特定内存大小的Java对象的创建图表。

　

　　Figure 3. Increase in service demand versus load for Java objects of different memory sizes