认识达内从这里开始

使用框架是程序员在开发软件的时候会经常用到的一个工具，而今天我们就一起来了解一下，java编程框架性能问题分析。

垃圾回收

总的来说，现在的垃圾回收机制的性能是能够与fork/join框架所匹配的：fork/join程序在运行时会产生巨大数量的任务单元，然而这些任务在被执行之后又会很快转变为内存垃圾。相比较于顺序执行的单线程程序，在任何时候，其对应的fork/join程序需要 多p倍的内存空间(其中p为线程数目)。基于分代的半空间拷贝垃圾回收器(也就是本文中测试程序所使用的Java虚拟机所应用的垃圾回收器)能够很好的处理这种情况，因为这种垃圾回收机制在进行内存回收的时候仅仅拷贝非垃圾内存单元。这样做，就避免了在手工并发内存管理上的一个复杂的问题，即跟踪那些被一个线程分配却在另一个线程中使用的内存单元。这种垃圾回收机制并不需要知道内存分配的源头，因此也就无需处理这个棘手的问题。

这种垃圾回收机制优势的一个 体现：使用这种垃圾回收机制，四个线程运行的Fib程序耗时仅为5.1秒钟，而如果在Java虚拟机设置关闭代拷贝回收(这种情况下使用的就是标记–清除垃圾回收机制了)，耗时需要9.1秒钟。

然而，只有内存使用率只有达到一个很高的值的情况下，垃圾回收机制才会成为影响扩展性的一个因素，因为这种情况下，虚拟机必须经常停止其他线程来进行垃圾回收。以下的数据显示出在三种不同的内存设置下(Java虚拟机支持通过额外的参数来设置内存参数)，加速比所表现出的差异：默认的4M的半空间，64M的半空间，另外根据线程数目按照公式(2+2p)M设置半空间。使用较小的半空间，在额外线程导致垃圾回收率攀高的情况下，停止其他线程并进行垃圾回收的开销开始影响加封。

鉴于上面的结果，我们使用64M的半空间作为其他测试的运行标准。其实设置内存大小的一个更好的策略就是根据每次测试的实际线程数目来确定。(正如上面的测试数据，我们发现这种情况下，加速比会表现的更为平滑)。相对的另一方面，程序所设定的任务粒度的阀值也应该随着线程数目成比例的增长。

内存分配和字宽

在上文提到的测试程序中，有四个程序会创建并操作数量巨大的共享数组和矩阵：数字排序，矩阵相乘/分解以及松弛。其中，排序算法应该是对数据移动操作(将内存数据移动到CPU缓存)以及系统总内存带宽， 为敏感的。为了确定这些影响因素的性质，我们将排序算法Sort改写为四个版本，分别对Byte字节数据，short型数据，int型数据以及long型数据进行排序。这些程序所操作的数据都在0~255之间，以确保这些对比测试之间的平等性。理论上，操作数据的字宽越大，内存操作压力也相应越大。

内存操作压力的增加会导致加速比的降低，虽然我们无法提供明确的证据来证明这是引起这种表现的 原因。但数据的字宽的确是影响程序的性能的。比如，使用一个线程，排序字节Byte数据需要耗时122.5秒，然而排序long数据则需要耗时242.5秒。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。