采用Jmeter测试工具对web系统作的负载测试，得出的响应报表，数据比较难懂，现作一具体说明。
以下是在一次具体负载测试中得出的具体数值，测试线程设置情况为：线程数：200，等待时间（ramp-up）：0秒，循环次数为永远，另：
线程组——这些元件用于指定运行的线程数和等候周期。每个线程模拟一个用户，而等候周期用于指定创建全部线程的时间。例如，线程数为5，等候时间为10秒，则创建每个线程之间的时间间隔为2秒。循环数定义了线程的运行时间。使用调度器，还可以设置运行的起始时间。
取样器——对于服务器HTTP、FTP或LDAP请求，这些元件是可配置请求。该教程仅侧重于Web Services请求。
监听器——这些元件用于请求数据的后期处理。例如，可以将数据保存到文件或用图表来说明结果。此时JMeter图表并没有提供许多配置选项；然而它是可扩展的，它始终可以添加额外的可视化效果或数据处理模块。
得出的图形报表和聚合报告如下所示：

 

一、图形报表

图表底部参数的含义如下：
样本数目是总共发送到服务器的请求数。
最新样本是代表时间的数字,是服务器响应最后一个请求的时间。
吞吐量是服务器每分钟处理的请求数。
平均值是总运行时间除以发送到服务器的请求数。
中间值是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。
偏离表示服务器响应时间变化、离散程度测量值的大小，或者，换句话说，就是数据的分布。

二、 聚合报告

图表含义说明如下：
Label：说明是请求类型，如Http，FTP等请求。
#Samples：也就是图形报表中的样本数目，总共发送到服务器的样本数目。
Average：也就是图形报表中的平均值，是总运行时间除以发送到服务器的请求数。
Median：也就是图形报表中的中间值，是代表时间的数字，有一半的服务器响应时间低于该值而另一半高于该值。
90%line：是指90%请求的响应时间比所得数值还要小。
Min：是代表时间的数字,是服务器响应的最短时间。
Max: 是代表时间的数字,是服务器响应的最长时间。
Error%:请求的错误百分比。
Throughput:也就是图形报表中的吞吐量，这里是服务器每单位时间处理的请求数，注意查看是秒或是分钟。
KB/sec:是每秒钟请求的字节数。

三、 使用分析
在测试过程中，平均响应时间是我们性能测试的一个重要衡量指标，但是在测试中，特别是在聚合报告中，得出的90%Line,我这里参考《《LoadRunner 没有告诉你的》之一——描述性统计与性能结果分析》，我认为90%Line等同于该文作者提出的90%响应时间,这个数值对我们性能测试分析也很有参考价值。90%响应时间是说在发送的请求中，90%的用户响应时间都比得到的数值上要短，同时说明，一个系统在应用时，90%的用户响应时间都能达到这个数值，那么就为系统性能分析提供了很好的参考价值。

 转自：百度文库

参数很多,一般我们用 -c 和 -n 参数就可以了. 例如:

./ab -c 1000 -n 1000 http://10.88.15.77/test.php

这个表示同时处理1000个请求并运行1000次index.php文件.
#ab -c 1000 -n 1000 http://10.88.15.77/test.php

Benchmarking 10.88.15.77 (be patient)

Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Finished 1000 requests

Server Software:        Apache/2.2.8
//平台apache 版本2.2.8
Server Hostname:        10.88.15.77
//服务器主机名
Server Port:            80
//服务器端口

Document Path:          /test.php

//测试的页面文档
Document Length:        1018 bytes
//文档大小

Concurrency Level:      1000
//并发数
Time taken for tests:   8.188731 seconds
//整个测试持续的时间
Complete requests:      1000
//完成的请求数量
Failed requests:        0
//失败的请求数量
Write errors:           0

Total transferred:      1361581 bytes
//整个场景中的网络传输量
HTML transferred:       1055666 bytes
//整个场景中的HTML内容传输量
Requests per second:    122.12 [#/sec] (mean)
//大家最关心的指标之一，相当于 LR 中的 每秒事务数 ，后面括号中的 mean 表示这是一个平均值
Time per request:       8188.731 [ms] (mean)
//大家最关心的指标之二，相当于 LR 中的 平均事务响应时间 ，后面括号中的 mean 表示这是一个平均值
Time per request:       8.189 [ms] (mean, across all concurrent requests)
//每个请求实际运行时间的平均值
Transfer rate:          162.30 [Kbytes/sec] received
//平均每秒网络上的流量，可以帮助排除是否存在网络流量过大导致响应时间延长的问题

Connection Times (ms)
              min mean[+/-sd] median   max
Connect:        4 646 1078.7     89    3291
Processing:   165 992 493.1    938    4712
Waiting:      118 934 480.6    882    4554
Total:        813 1638 1338.9   1093    7785
//网络上消耗的时间的分解，各项数据的具体算法还不是很清楚

Percentage of the requests served within a certain time (ms)
50%   1093
66%   1247
75%   1373
80%   1493
90%   4061
95%   4398
98%   5608
99%   7368
100%   7785 (longest request)
//整个场景中所有请求的响应情况。在场景中每个请求都有一个响应时间，其中50％的用户响应时间小于1093 毫秒，60％ 的用户响应时间小于1247 毫秒，最大的响应时间小于7785 毫秒

      由于对于并发请求，cpu实际上并不是同时处理的，而是按照每个请求获得的时间片逐个轮转处理的，所以基本上第一个Time per request时间约等于第二个Time per request时间乘以并发请求数
转自：http://blog.sina.com.cn/s/blog_3c9872d00100dbox.html

配置
(1)复制PHP.INI文件到正确位置
在PHP解压的目录下运行
#cp php.ini-dist /usr/local/php/lib/php.ini
(2)编辑apache配置文件httpd.conf
#vi /usr/local/apache2219/conf/httpd.conf
要改的有如下几处:
一般都在
#AddType application/x-tar .tgz
下加一行
AddType application/x-httpd-php .php
还有找到
DirectoryIndex index.html index.html.var
在后面加 index.php 让它把index.php做为默认页
再找
#ServerName
把#去掉,后面的IP改成你的IP.
找到
DocumentRoot "/usr/local/apache2219/htdocs"
把/usr/local/apache2/htdocs改为你存放网页文件的路径

比如我是放在/myweb目录下,所以我以后上传PHP文件就放在/myweb目录下,然后用IP访问,就能看到首页了
差不多就这些了,至于apache2其它优化,请看
http://www.phpv.net/
里的apache配置那一分类.
保存httpd.conf文件.

写个index.php
内容：
<?php
phpinfo();
?>

启动apache
/usr/local/apache2219/bin/apachectl start

访问：
http://ip/

    所谓PhraseQuery，就是通过短语来检索，比如我想查“big car”这个短语，那么如果待匹配的document的指定项里包含了"big car"这个短语，这个document就算匹配成功。可如果待匹配的句子里包含的是“big black car”，那么就无法匹配成功了，如果也想让这个匹配，就需要设定slop，先给出slop的概念：slop是指两个项的位置之间允许的最大间隔距离，下面我举例来解释：

   我的待匹配的句子是：the quick brown fox jumped over the lazy dog.

   例1： 如果我想用“quick fox”来匹配出上面的句子，我发现原句里是quick [brown] fox，就是说和我的“quick fox”中间相差了一个单词的距离，所以，我这里把slop设为1，表示quick和fox这两项之间最大可以允许有一个单词的间隔，这样所有“quick [***] fox”就都可以被匹配出来了。

   例2：如果我想用“fox quick”来匹配出上面的句子，这也是可以的，不过比例1要麻烦，我们需要看把“fox quick”怎么移动能形成“quick [***] fox”，如下表所示，把fox向右移动3次即可：

    例3：如果我想用“lazy jumped quick”该如何匹配上面的句子呢？这个比例2还要麻烦，我们要考虑3个单词，不管多少个单词，slop表示的是间隔的最大距离，详细起见，我们分别来看每种组合：(我的待匹配的句子是：the quick brown fox jumped over the lazy dog.)

• lazy jumped:原句是jumped [over] [the] lazy，就是说它们两个之间间隔了2个词,如下所示：需要把lazy向右移动4位

•   lazy jumped quick：我们主要看lazy和quick，但是由于jumped是在中间，所以移动的时候还是要把jumped考虑在内，原句里lazy和quick的关系是：quick [brown] [fox] [jumped] [over] [the] lazy ，quick lazy中间间隔了5个词，所以如下图所示，把lazy向右移动8次

•  最后是jumped qucik，这里不详细画表格了，大家可以自己试试，应该是把jumped向右移动4次。

   综合以上3种情况，所以我们需要把slop设为8才令“lazy jumped quick”可以匹配到原句。

第一种情形：部分静态页面需要apache处理，不转发给后端的tomcat

JkMount  /*    router    ###默认将所有请求转发给tomcat处理
JKUnmount /*.php   router    ###php请求不交给tomcat处理
JKUnmount /*.htm   router    ###htm请求不交给tomcat处理
JKUnmount /*.html  router ###html请求不交给tomcat处理

JKUnmount     /css/*       router    ###css请求不交给tomcat处理
JKUnmount     /js/*         router     ###js请求不交给tomcat处理

JKUnmount  /image/*   router    ###image请求不交给tomcat处理

第二种情形：将所有请求转发到后端tomcat之后，将不同路径定位给不同的tomcat

JkMount /*           router

JkMount /login/*     tomcat1

JkMount /shop/*     tomcat2

JkMount /buy/*       tomcat3

注意，这种情形下，必须要有这样的处理：

worker.list=router,jkstatus,tomcat1,tomcat2,tomcat3

如果是第一种情形，tomcat1,tomcat2,tomcat3是不需要写在上面这个地方的

而是写在下面：

worker.router.balance_workers=tomcat1,tomcat2,tomcat3

实际使用中，应该是上述两种情形相结合使用的较多，将静态内容交给apache处理，然后将动态内容分布到不同的服务器上。

JkMount把匹配的转发到指定服务器.
JkUnMount把匹配的不转发到指定服务器.
JkUnMount选项的级别高于JkMount.
单独有JkMount规则有效,但单独有JkUnMount无效,JkUnMount与JkMount要成对出现.

Xml代码 [url=http://tyler-zhou.javaeye.com/blog/507158]

extra/httpd-mpm.conf 模块  

上边一样的就不贴了，主要是下边的配置，因为我用了mod_security模块，所以要做一些配置，这里不做解释了，写的很详细，我比较喜欢在配置文件里把容易忘记的地方写上文档。毕竟这东西配完了就不再动了，很容易忘记

# WinNT MPM

# ThreadsPerChild: constant number of worker threads in the server process

# MaxRequestsPerChild: maximum  number of requests a server process serves

#注意：ThreadLimit指令应当放在ThreadsPerChild之前，否则ThreadsPerChild指令生效后ThreadLimit会失效，而导致不必要的错误 ThreadLimit必须大于等于ThreadsPerChild

#对于mpm_winnt，ThreadLimit的默认值是1920；对于其他MPM这个值是64

#ThreadLimit 这个指令设置了每个子进程可配置的线程数ThreadsPerChild上限。任何在重启期间对这个指令的改变都将被忽略，但对ThreadsPerChild的修改却会生效。

#ThreadLimit 使用这个指令时要特别当心。如果将ThreadLimit设置成一个高出ThreadsPerChild实际需要很多的值，将会有过多的共享内存被分配。

#如果将ThreadLimit和ThreadsPerChild设置成超过系统的处理能力，Apache可能无法启动，或者系统将变得不稳定。该指令的值应当和ThreadsPerChild大致保持一致

#ThreadsPerChild 每个子进程建立的常驻的执行线程数。默认值是25。子进程在启动时建立这些线程后就不再建立新的线程了。

<IfModule mpm_winnt_module>

    ThreadLimit            2000

    ThreadsPerChild        2000

    MaxRequestsPerChild    2000

</IfModule>

Apache Harmony 是 2005 年 5 月宣布的开放源码 Java SE 实现，本文是由 5 部分组成的 进入 Harmony 世界 系列文章的第一篇，这个系列主要介绍 Apache Harmony 项目的内部实现，最新发展现状和开源 Java 开发的模式，并鼓励和欢迎大家参与到 Harmony 的社区中来。本文是 5 个系列的第一篇，概括介绍了 Harmony 项目的背景，技术架构，社区运作和未来的方向。

本文是 5 个系列的第一篇，概括介绍了 Harmony 项目的背景，技术架构，社区运作和未来的方向。

Apache Harmony 的背景

Apache Harmony 的提案在 2005 年 5 月被 Apache 软件基金会（ASF）接受，并且按照 ASF 惯例成为一个孵化器（incubator）项目。

Harmony 为自己定了两个目标，首先是开发出一个独立并且与现有 JDK 兼容的 Java SE 5 实现，并且以 Apache 软件许可证 2.0 版发行；其次是建立一个开放的模块化运行时架构，包括虚拟机和类库之间及其内部的模块化，并通过这个平台，允许社区在此基础上自由定制自己的 Java 实现，或者对某个模块单独进行创新。

Apache Harmony 项目的成立以及它的这两个目标具有很大的现实意义。首先，由于商业JDK的流行性，它们几乎成为事实上的标准，所以 Harmony 必须与它们保持高度的兼容，才能够使应用程序的迁移成本最低，也就相对容易被用户所接受；其次，Harmony 存在的重要意义之一就在于这是一个属于开源社区的 Java 平台，在这个平台上，社区可以自由的移植和创新，而一个开放的模块化的架构，将为移植和创新带来最大的便利性；最后，Apache 软件许可证是一个对商业公司和开源社区都比较友好的开源许可证，因此 Harmony 可以给最大范围的开发人员和用户带来便利。本文和本系列后续文章将详细介绍 Harmony 在兼容性和模块化方面的努力，以及这些目标带来的价值。

也许正是基于以上一些原因，Harmony 项目成立仅仅一年多一点的时间，就得到了广泛的支持和关注，并且得以飞速发展。目前，Apache Harmony 已经拥有了一个活跃的开发社区，并且接受了来自公司，学校和个人的多次捐赠。IBM 在 developerWorks 上提供了一个 Java 虚拟机环境的免费下载，以支持 Harmony 项目的开发，还多次捐赠了核心类库的实现和测试代码，在 IBM 英国 Hursley 软件开发实验室和中国软件开发中心各有一个开发团队积极参与 Harmony 项目。此外 Harmony 项目还接受了三个 Java 虚拟机实现的捐赠，另外还有一个开源 Java 虚拟机 SableVM 正在积极的与 Harmony 社区合作以实现与 Harmony 类库的集成。Java SE 实现难度最大的是其规模庞大的类库，而最近的类库 API 覆盖率统计表明，Harmony 的 J2SE 1.4.2 类库 API 的覆盖率已经超过 80%，Java SE 5 的覆盖率已经达到 79% 以上。目前经不完全测试，在 Harmony 上已经可以良好运行 Eclipse、JEdit、Ant 等流行的 Java 工具，并且可以部分运行 Tomcat 和 Geronimo 等企业应用。

技术架构

如前所述，Apache Harmony 非常注重模块化，从图一中，可以对 Apache Harmony 的总体架构有一个初步的感觉。与所有其他 Java SE 实现类似的是，Harmony 从大体上可以分为三个层次，最下层是操作系统，中间是 Java 虚拟机，最上层是 Java 类库。而 Harmony 的特点在于:

• 虚拟机和类库内部被高度模块化，在 Harmony 中，类库在功能和 Java Package 的基础上被分成 31 个模块，而虚拟机也被分成即时编译器， 内存管理， 线程管理，Java 本地接口等等模块。每个模块都有一定的接口定义，从而有可能单独被替换成不同的实现。
• 操作系统层次与虚拟机层次之间的接口由 Port Layer 定义。Port Layer 封装了不同的操作系统的差异，为虚拟机和类库的本地代码提供了一套统一的 API 访问底层系统调用。
• 虚拟机与类库之间的接口除了 Java 规范定义的 JNI，JVMITI 之外，加入了一层虚拟机接口，主要由内核类（Kernel Class）和本地代码 VMI 组成，实现了虚拟机接口的虚拟机实现都可以使用 Harmony 的类库实现，并且可以被 Harmony 提供的同一个 Java 启动程序启动。

图一 Apache Harmony 技术架构鸟瞰图

本节将分别对 Port Layer，VMI 和 Java 统一启动程序作进一步的介绍。

Apache Harmony Port Layer

Apache Harmony 在操作系统与虚拟机之间定义了一个 Port Layer，Port Layer 是由一个标准 C 的库（Port Library）来实现得，Port Library 与操作系统交互，为虚拟机和类库的本地代码提供了一个平台无关的标准 C 语言 API 访问系统调用。诸如文件 I/O，网络 I/O， 内存操作，信号处理，以及错误处理等等功能，都被纳入 Port Library 的范围。

通过使用 Port Library， 所有（目前还没有做到，但这是设计目标）与操作系统平台相关的内容被封装在一个库里面，虚拟机和类库的其他部分都可以尽可能以平台无关的方式实现出来。这样一来，将 Java SE 的庞大类库和虚拟机代码移植到其他操作系统的工作就可以被快速的开发出来，从而大大提高了可移植性和程序的可维护性。

在 Apache 软件基金会资助的开源项目中，有一个类似的平台无关库叫做 Apache Portable Runtime（APR）， 这个项目是从 Apache Http Server 等项目的开发过程中提炼和分离出来的，目前已经比较成熟，它与 Harmony 的 Port Layer 的目标有类似之处，但是也有明显的不同，从而使得目前 APR 还不适合作为 Java 虚拟机和类库的平台无关库实现。在本系列后续文章中会有单独的文章详细介绍 Harmony Port Library 的设计特点，并与 APR 进行比较。

Apache Harmony 虚拟机接口

Apache Harmony 虚拟机接口定义了类库和虚拟机之间的接口，Java 规范已经定义了一些虚拟机的 API，比如 Java 本地接口（JNI）， Java 虚拟机工具接口（JVMTI）等，但是 Java 规范并没有定义类库和虚拟机之间的接口。Harmony 为了模块化和可移植性的要求，定义了虚拟机接口（VMI），只要是实现了该接口的虚拟机就是 Harmony 兼容虚拟机，从而可以与 Harmony 的类库实现互操作，并且可以与 Harmony 提供的 Java 启动程序协作。

Apache Harmony 虚拟机接口分为三个部分，一部分是 Java 语言接口，由 23 个内核类（Kernel Class）组成，另一部分是 C 语言接口，由 10 个函数组成，最后一部分就是标准 JNI。

• 内核类的提出是因为少数核心的公共类是与虚拟机密切相关（VM-specific）的，它们都是属于 java.lang，java.lang.ref，java.lang.reflect 和 java.security 等几个核心的包，比如说 java.lang.ClassLoader， java.lang.ref.WeakReference 等。随着 Java 版本的升级，核心类的数量也可能会增加。Harmony 的类库实现为大多数核心类定义了实现模板。VM 的开发人员可以从零开始实现这些核心类，也可以在 Harmony 提供的模板基础上开始开发。
• 虚拟机接口还定义了 VM 必须实现的 10 个 C 函数，用来访问虚拟机和类库共享的数据结构和接口，比如说访问操作系统抽象库（Port Library），虚拟机本地存储空间等。
• 虚拟机的最后一部分就是标准 JNI，它在这里的主要用途是允许从 Java 类库的本地链接库中创建 Java 对象。

应该说虚拟机接口是一个相对宽松的接口，它并不要求对虚拟机和类库特殊的耦合，对垃圾收集，同步和对象的数据结构等等也没有特殊的规定。另外一个著名的开源 Java SE 类库 GNU Classpath 也有类似的虚拟机接口，本系列后续文章将详细介绍 Harmony VMI，并且与 GNU Classpath 比较。

Apache Harmony 启动程序

Apache Harmony 提供了一个启动程序，也就是通常我们用来运行 Java 程序的 java 和 javaw 命令的实现，这个启动程序是个多目标的启动器，可以根据命令行参数启动不同的虚拟机，也可以支持虚拟机特有的选项，如属性文件或命令行参数等。这一切都是基于虚拟机接口，Port Library 和标准 JNI 实现的。

在进一步介绍启动程序之前，需要先介绍一下 Harmony Development Kit（HDK）和 Harmony JRE 的目录结构，请参考图二。HDK 是一个完整的开发包，不仅仅包括 Harmony 用户所需的所有内容，也提供 Harmony 开发人员所有的静态链接库和头文件，使得他们可以在此基础上对其中任何一部分进行修改和重新构建。

• <hdkbase>/jdk/jre， 这个目录包含了标准的 JRE 结构，如 bin 和 lib 目录等。
• <hdkbase>/jdk/include，这个目录包含了标准的 JDK 头文件，如 jni.h 等。
• <hdkbase>/include， 这个目录包含了 Harmony 独有的并且被多个模块共享的头文件
• <hdkbase>/lib， 这个目录包含了编译 Harmony 本地代码所需的静态链接库文件，如在 Windows 平台，就包含了 .lib 文件，而在 Linux 平台，则包含了 .a 文件。

对于启动程序来说，需要特别注意的是 <hdkbase>/jdk/jre/bin 目录，在这里可以包含多个虚拟机实现，每一个实现应该被放在该目录的一个子路径里（比如 vm1， vm2 等），缺省的虚拟机实现在 <hdkbase>/jdk/jre/bin/default 目录，如果不指定特定参数，该虚拟机会被启动程序使用。一般来讲，每个虚拟机实现应该包含虚拟机实现文件和资源文件，尤其是必须有三个部分的虚拟机接口的实现。

图二 HDK 目录结构

在调用启动程序的时候，有两个参数被用来指定启动哪一个虚拟机实现，-vmdir 用来指定虚拟机所在的子目录，-vm 用来指定实现了JNI接口的动态链接库，比如要使用 IBM 提供的 VME，而 VME 放在 vm1 目录下的话，启动程序的命令行就应该像:

java -vmdir:vm1 -vm :clearvm.dll …

Harmony 的启动程序在启动时将执行以下任务：

• 生成一个 Port Library 实例并且装载它
• 装载虚拟机本地动态链接库
• 初始化内核类
• 调用 JNI_CreateJavaVM（…）， main（…）， JarRunner 等

Apache Harmony 类库的模块化

Apache Harmony 将类库分成易于管理的模块，这样做的目的是

• 使 Java 类库的开发工作易于管理，开源社区的参与者可以集中开发他擅长的模块
• 方便模块装配， 用户可以自由选择模块提供者，可以自由替换或者升级任一模块
• 使法律方面的风险易于管理，如果开发人员以前接触过其他 Java SE 实现的代码，他也可以参与以前未接触过的模块开发。
• 方便代码捐献

类库的模块实际上是由一组实现相关的功能的 Java 类和本地程序组成的，目前它们按照包的级别来划分，也就是说不会有两个属于同一个 Java package 的类出现在两个不同的模块里（内核类所在的包除外，但也仅在内核类模块和另一个类库模块中出现）。这些模块可以包含私有的内部实现，但是必须导出 Java API 参考文档规定标准 API，也可以导出 Harmony 独有的 API，但是这些 API 并不鼓励用户使用，只是供其他模块调用的。

模块的鉴别方法是: 首先根据 Java 规范，确定各 Java 包之间的依赖关系；然后寻找弱耦合的部分，将本身内聚的包组织在一起，最后在社区讨论哪部分类库应该可以拆开独立成一个模块。目前 Harmony 将 Java SE 5 规定的类库分成了三十一个模块，在 Java 升级之后，模块的数量可能会增加。目前这三十一个模块包括:

• ACCESSIBILITY
• ANNOTATION
• APPLET
• ARCHIVE
• AUTH
• AWT
• BEANS
• CONCURRENT
• CRYPTO
• IMAGEIO
• INSTRUMENT
• JMX
• JNDI
• LANG-MANAGEMENT
• LOGGING
• LUNI （lang， util， net， io）
• MATH
• NIO-CHANNELS
• NIO-CHARSET
• ORB
• PREFS
• PRINT
• REGEX
• RMI
• SECURITY
• SOUND
• SQL
• SWING
• TEXT
• X-NET
• XML

在 Harmony 的代码资源库中，每个模块的源文件都保存在自己的各自的路径中，如果使用 Eclipse 做开发工具，每个模块就可以看作一个单独的工程项目。特别需要注意的是，按照 jar 文件的规范，在每个模块都有一个 META-INF/manifest.mf 文件，在这个文件中定义了该模块的 OSGI 元数据，其中最重要的就是该模块导入导出的 Java package。

Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: Harmony NIO Bundle-SymbolicName: org.apache.harmony.nio Bundle-Version: 1.0.0 Bundle-ClassPath: . Eclipse-JREBundle: true Import-Package: java.io， java.lang， java.lang.ref， java.lang.reflect， java.net， java.nio.charset， java.security， java.util， org.apache.harmony.kernel.vm， org.apache.harmony.luni.net， org.apache.harmony.luni.platform， org.apache.harmony.luni.util， tests.support;hy_usage=test;resolution:=optional， tests.util;hy_usage=test;resolution:=optional Export-Package: java.nio， java.nio.channels， java.nio.channels.spi， org.apache.harmony.nio

在编译之后，每一个模块将被打包成一个 jar 文件，如果该模块有本地代码，则该模块的本地代码被编译成一个单独的动态链接库文件。如图二所示，hyluni.dll 就是 LUNI（lang， util， net， io）模块的本地二进制代码库，而在 <hdkbase>/jdk/jre/lib/boot 目录中，对应 LUNI 模块的则有一个 luni.jar。

Apache Harmony 的开发方法

近年来，开源软件相关的知识产权问题越来越受到关注。为了保证对知识产权的尊重，保持 Harmony 代码的纯洁性和原创性，除了 Apache 软件基金会原有的通用规则之外，Harmony 开发社区花了很大的精力来定义 Harmony 接受代码捐赠和接受项目参与者的规则。

Harmony 要求每个开发人员在参与代码捐赠之前，必须完成一个问卷调查，问卷的主要内容是关于该开发人员以前是否接触过其他 Java SE 实现，如果他接触过其他专有代码的某一部分，他就不能参与 Harmony 相应模块的代码工作（但也有一些特殊的例外情况）。同时，任何现有代码的捐赠必须提供代码的"血统"信息。

知识产权之外的另一个重要问题就是兼容性。Harmony 的目标产生一个 Java SE 5 兼容的实现，它不仅仅要完全遵循 Java API 参考定义的 Java SE 规范，Java 语言规范以及 Java 虚拟机规范；同时还必须保证与现有 Java SE 参考实现的兼容性，为此，Harmony 采用了测试驱动开发模式，以单元测试用例来保证 Harmony 的行为和参考实现一致。最重要的是，Harmony 正在试图申请 Java SE 5 JCK 兼容性测试的许可证，因为只有被 JCK 认证过，Harmony 才能正式被称为 Java 兼容的实现。

除了单元测试之外，Harmony 还会通过一些已有的成熟的 Java 程序来作为黑盒测试的应用，测试 Harmony 是否已经可以支持这些应用。目前 Harmony 可以运行 Eclipse，Tomcat，JEdit 等 Java 程序。Harmony 提供了一个工具，鼓励 Java 程序作者将他们的程序运行在 Harmony 上，并且通过这个工具将运行结果反馈给 Harmony 开发社区。

总的来说，Harmony 采用以下几种方式来衡量开发进度：

• 粗粒度层次上，可以衡量一个模块是否已经开发。
• 使用工具比较 Harmony 和参考实现兼容性，比如使用 JAPI 检测 Harmony 的 API 覆盖率。
• 使用工具检查测试覆盖率，检查 Harmony 的各种行为是否得到充分的测试。
• 支持成熟的 Java 应用程序列表。
• 将来的目标是通过 JCK 测试。

本系列后续文章将进一步介绍 Harmony 开发中的最佳实践。

Apache Harmony 未来的发展方向

Harmony 的一个重要目标是类库的模块化。Harmony 将进一步采用 OSGi 运行时框架技术，根据模块元数据描述，自动装载模块。并且还将努力实现以下目标：

• 允许同时装载同一模块的不同版本。
• 通过模块的 MANIFEST.MF 元数据文件控制其所包含的 Java package 的可见性。
• Java 类和相应的本地代码的启动/停止/卸载等生命周期管理。

你能为 Harmony 做些什么

目前 Harmony 已经建立了一个相当活跃的开发社区，并且非常欢迎更多的人参与进来，包括参与 Harmony 的开发，移植 Harmony 到其他平台（目前 Harmony 只有 IA32 的 Windows 和 Linux 版本），撰写文档，在 Harmony 上运行成熟的 Java 应用检查其实现的覆盖率和兼容性等等。除此之外，同样重要的是，你还可以参与远未成熟的 Harmony 用户社区，试用 Harmony，参与 Harmony 的讨论，等等。Harmony 是一个属于所有人的 Java 平台。

总结

• Harmony 的目标是一个完全兼容的开源的 JSE 实现
• Harmony 投入巨大的努力保证知识产权的纯洁性
• Harmony 社区的目标是创建一个一流的模块化的运行时环境
• Harmony 在过去的一年中取得了巨大的成就
• Harmony 欢迎任何有兴趣的开发者

转载自 ibm dw http://www.ibm.com/developerworks/cn/java/j-lo-harmony1/

Discovery组件被用以查找可插拔接口的实现实例，它提供了一种通用的实例化这些实现的方式，而且可以管理单例（工厂）的生命周期。本质上来讲，就是定位那些实现了给定Java接口的类，并实例化。除此之外，Discovery还可以用以在给定的classpath中查找并加载资源文件。

Discovery组件在查找所有的实现类的时候需要预先将允许被查找的实现类配置到默认的配置文件中，默认的配置文件为：

/META-INF/services/<YOUR Interface whole name including pkg name>， Discovery将依次加载该文件中配置的允许加载的实现类。

下面将举例说明：

首先定义一个Interface：Action

Java代码

1. package com.javaeye.terrencexu.discovery;   
2.   
3. public interface Action {   
4.   
5.     public String getName();   
6.        
7. }  

package com.javaeye.terrencexu.discovery;
public interface Action {
public String getName();
}

然后在不同的包里分别实现Action接口，如下(请注意包名)

Java代码

1. package com.javaeye.terrencexu.discovery.impl;   
2.   
3. import com.javaeye.terrencexu.discovery.Action;   
4.   
5. public class CreateAction implements Action {   
6.   
7.     @Override  
8.     public String getName() {   
9.         return "Create Action";   
10.     }   
11.   
12. }  

package com.javaeye.terrencexu.discovery.impl;
import com.javaeye.terrencexu.discovery.Action;
public class CreateAction implements Action {
@Override
public String getName() {
return "Create Action";
}
}

Java代码

1. package com.javaeye.terrencexu.discovery.impl;   
2.   
3. import com.javaeye.terrencexu.discovery.Action;   
4.   
5. public class DeleteAction implements Action {   
6.   
7.     @Override  
8.     public String getName() {   
9.         return "Delete Action";   
10.     }   
11.   
12. }  

package com.javaeye.terrencexu.discovery.impl;
import com.javaeye.terrencexu.discovery.Action;
public class DeleteAction implements Action {
@Override
public String getName() {
return "Delete Action";
}
}

Java代码

1. package com.javaeye.terrencexu.discovery.impl2;   
2.   
3. import com.javaeye.terrencexu.discovery.Action;   
4.   
5. public class AddAction implements Action {   
6.   
7.     @Override  
8.     public String getName() {   
9.         return "Add Action";   
10.     }   
11.   
12. }  

package com.javaeye.terrencexu.discovery.impl2;
import com.javaeye.terrencexu.discovery.Action;
public class AddAction implements Action {
@Override
public String getName() {
return "Add Action";
}
}

Java代码

1. package com.javaeye.terrencexu.discovery.impl2;   
2.   
3. import com.javaeye.terrencexu.discovery.Action;   
4.   
5. public class RemoveAction implements Action {   
6.   
7.     @Override  
8.     public String getName() {   
9.         return "Remove Action";   
10.     }   
11.   
12. }  

package com.javaeye.terrencexu.discovery.impl2;
import com.javaeye.terrencexu.discovery.Action;
public class RemoveAction implements Action {
@Override
public String getName() {
return "Remove Action";
}
}

接下来将定义配置文件，按序定义允许被加载的实现类，该文件默认存在位置为/META-INF/services/，文件名为com.javaeye.terrencexu.discovery.Action，文件内容如下：

Java代码

1. # Display in order   
2.   
3. com.javaeye.terrencexu.discovery.impl.CreateAction   
4. com.javaeye.terrencexu.discovery.impl.DeleteAction   
5. com.javaeye.terrencexu.discovery.impl2.AddAction  

# Display in order
com.javaeye.terrencexu.discovery.impl.CreateAction
com.javaeye.terrencexu.discovery.impl.DeleteAction
com.javaeye.terrencexu.discovery.impl2.AddAction

这样所有的准备材料就都已经齐全了，接下来可以验证一把了，如下：

Java代码

1.  /**  
2.  *  CreateAction/DeleteAction/AddAction have been defined in /META-INF/services/com.javaeye.terrencexu.discovery.Action  
3.  *    
4.  *  And the order is CreateAction > DeleteAction > AddAction  
5.  */  
6. @SuppressWarnings("unchecked")   
7. public void testGetAllProviders() {   
8.     String[] expectedResults = new String[] {"Create Action", "Delete Action", "Add Action"};   
9.            
10.     Enumeration<Action> enu = Service.providers(Action.class);   
11.   
12.     int count = 0;   
13.     while (enu.hasMoreElements()) {   
14.         Action action = enu.nextElement();   
15.         assertTrue("The action name should be \"" + expectedResults[count] + "\", but actually is \"" + action.getName() + "\"",    
16.                action.getName().equals(expectedResults[count]));   
17.         count ++;   
18.     }   
19.            
20.     assertEquals(count, expectedResults.length);   
21. }  

 /**
*  CreateAction/DeleteAction/AddAction have been defined in /META-INF/services/com.javaeye.terrencexu.discovery.Action
*
*  And the order is CreateAction > DeleteAction > AddAction
*/
@SuppressWarnings("unchecked")
public void testGetAllProviders() {
String[] expectedResults = new String[] {"Create Action", "Delete Action", "Add Action"};
Enumeration<Action> enu = Service.providers(Action.class);
int count = 0;
while (enu.hasMoreElements()) {
Action action = enu.nextElement();
assertTrue("The action name should be \"" + expectedResults[count] + "\", but actually is \"" + action.getName() + "\"",
action.getName().equals(expectedResults[count]));
count ++;
}
assertEquals(count, expectedResults.length);
}

可以发现，因为RemoveAction没有被配置到service文件中，所以将不会被加载，另外一点儿就是，配置文件中的定义顺序即加载顺序。

除此之外，Discovery提供了singleton模式加载唯一实现，并且该实现将被缓存在cache中，除非通过显示的调用release()方法释放缓存，否则所有之后的调用，都将返回初次调用加载的Action。

Java代码

1. public void testFindCreateAction() {   
2.     try {   
3.         // Load provider com.javaeye.terrencexu.discovery.impl.CreateAction   
4.         Action createAction = (Action) DiscoverSingleton.find(Action.class, CreateAction.class.getName());   
5.         assertEquals("Create Action", createAction.getName());   
6.     } finally {   
7.         DiscoverSingleton.release();   
8.     }   
9. }  

public void testFindCreateAction() {
try {
// Load provider com.javaeye.terrencexu.discovery.impl.CreateAction
Action createAction = (Action) DiscoverSingleton.find(Action.class, CreateAction.class.getName());
assertEquals("Create Action", createAction.getName());
} finally {
DiscoverSingleton.release();
}
}

还有一点需要说明的是，如果定义了默认的service文件，无论通过singleton模式加载的实现类有没有被配置在service文件中，都将默认加载配置中文中的第一个Action，比如上文中的CreateAction。

Java代码

1. public void testFindDeleteActionInConfig() {   
2.     try {   
3.         // Load provider com.javaeye.terrencexu.discovery.impl.CreateAction   
4.         Action deleteAction = (Action) DiscoverSingleton.find(Action.class, DeleteAction.class.getName());   
5.            
6.         // As the default configuration file defines the CreateAction as the first element, so you will always get the CreateAction as singleton.    
7.         assertEquals("Create Action", deleteAction.getName());   
8.     } finally {   
9.         DiscoverSingleton.release();   
10.     }   
11. }  

public void testFindDeleteActionInConfig() {
try {
// Load provider com.javaeye.terrencexu.discovery.impl.CreateAction
Action deleteAction = (Action) DiscoverSingleton.find(Action.class, DeleteAction.class.getName());
// As the default configuration file defines the CreateAction as the first element, so you will always get the CreateAction as singleton.
assertEquals("Create Action", deleteAction.getName());
} finally {
DiscoverSingleton.release();
}
}

那么如果必须使用service文件，又想通过singleton模式加载某特定的实现类该怎么办呢？可以通过传递Properties到DiscoverSingleton中去改变它的行为，如下：

Java代码

1. public void testFindDeleteActionWithProperty() {   
2.     try {   
3.         Properties props = new Properties();   
4.         props.setProperty(Action.class.getName(), DeleteAction.class.getName());   
5.            
6.         // Load provider com.javaeye.terrencexu.discovery.impl.CreateAction   
7.         Action deleteAction = (Action) DiscoverSingleton.find(Action.class, props);   
8.         assertEquals("Delete Action", deleteAction.getName());   
9.     } finally {   
10.         DiscoverSingleton.release();   
11.     }   
12. }  

public void testFindDeleteActionWithProperty() {
try {
Properties props = new Properties();
props.setProperty(Action.class.getName(), DeleteAction.class.getName());
// Load provider com.javaeye.terrencexu.discovery.impl.CreateAction
Action deleteAction = (Action) DiscoverSingleton.find(Action.class, props);
assertEquals("Delete Action", deleteAction.getName());
} finally {
DiscoverSingleton.release();
}
}

除了加载类之外，很多情况下我们还想加载资源文件，比如在你的classpath下有一个配置文件为/conf/testResource，下面我们通过Discovery去加载该资源文件：

Java代码

1. public void testFindResources() {   
2.     ClassLoaders loaders = new ClassLoaders();   
3.     ClassLoader cl = getClass().getClassLoader();   
4.     if(cl != null) {   
5.         loaders.put(getClass().getClassLoader(), true);   
6.     } else {   
7.         loaders.put(JDKHooks.getJDKHooks().getSystemClassLoader(), true);   
8.     }   
9.        
10.     String name = "conf/testResource";   
11.     DiscoverResources discovery = new DiscoverResources(loaders);   
12.     ResourceIterator iter = discovery.findResources(name);   
13.        
14.     while(iter.hasNext()) {   
15.         Resource resource = iter.nextResource();   
16.         URL url = resource.getResource();   
17.         System.out.println(url);   
18.     }   
19. }  

public void testFindResources() {
ClassLoaders loaders = new ClassLoaders();
ClassLoader cl = getClass().getClassLoader();
if(cl != null) {
loaders.put(getClass().getClassLoader(), true);
} else {
loaders.put(JDKHooks.getJDKHooks().getSystemClassLoader(), true);
}
String name = "conf/testResource";
DiscoverResources discovery = new DiscoverResources(loaders);
ResourceIterator iter = discovery.findResources(name);
while(iter.hasNext()) {
Resource resource = iter.nextResource();
URL url = resource.getResource();
System.out.println(url);
}
}

Discovery还有其他一些功能这里就不在详细的一一赘述了，可以参考http://commons.apache.org/discovery/index.html进一步详细了解。

下图是我的例子的目录结构，仅供参考：

然后附件中有source code，仅供参考。