注：在下面做的介绍都是以Weblogic8.1为例的，其它版本的Weblogic可能会有些许不同。

       1) 设置JAVA参数；

       a) 编辑Weblogic Server启动脚本文件；

         BEA_HOME\user_projects\domains\domain-name\startWebLogic.cmd(startWebLogic.sh on Unix)

         BEA_HOME\user_projects\domains\domain-name\startManagedWebLogic.cmd(startManagedWebLogic.sh on Unix)

b) 编辑set JAVA_OPTIONS命令，如：set JAVA_OPTIONS=-Xms256m –Xmx256m；

c) 保存，重启即可。

注：在WebLogic中，为了获得更好的性能，BEA公司推荐最小Java堆等于最大Java堆。

2) 开发模式 vs. 产品模式；

开发模式和产品模式的一些参数的默认值不同，可能会对性能造成影响，下面是对性能有影响的参数列表：

       通过启动管理控制台，在域（如：mydomain）> 配置 > 常规选择产品模式。

3) 尽量开启本地I/O；

通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> 配置 > 调整选择启用本地I/O。

注：此值也可通过手动的修改config.xml配置文件。

4) 调优执行队列线程；

a) 修改默认执行线程数

在这里，执行队列的线程数表示执行队列能够同时执行的操作的数量。但此值不是设的越大越好，应该恰到好处的去设置它，太小了，执行队列中将会积累很多待处理的任务，太大了，则会消耗大量的系统资源从而影响整体的性能。在产品模式下默认为25个执行线程。

为了设置理想的执行队列的线程数，我们可以启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> 监视 > 性能中监控最大负载时执行队列的吞吐量和队列中的等待请求数，据此确定理想的数值。

       理想的默认执行线程数是由多方面的因素决定的，比如机器CPU性能、总体体系架构、I/O、操作系统的进程调度机制、JVM的线程调度机制。随着CPU个数的增加，WebLogic可以近乎线性地提高线程数。线程数越多，花费在线程切换的时间也就越多；线程数越小，CPU可能无法得到充分的利用。为获取一个理想的线程数，需要经过反复的测试。在测试中，可以以25*CPU个数为基准进行调整。当空闲线程较少，CPU利用率较低时，可以适当增加线程数的大小（每五个递增）。对于PC Server和Windows 2000，则最好每个CPU小于50个线程，以CPU利用率为90%左右为最佳。

       通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置中修改线程计数。

       b) 设定执行队列的溢出条件；

       Weblogic Server提供给默认的执行队列或用户自定义的执行队列自定义溢出条件的功能，当满足此溢出条件时，服务器改变其状态为“警告”状态，并且额外的再分配一些线程去处理在队列中的请求，而达到降低队列长度的目的。

       通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）> Execute Queue > weblogic.kernel.Defalt > 配置下面几项：

         队列长度：此值表示执行队列中可容纳的最大请求数，默认值是65536，最后不要手动改变此值。

         队列长度阈值百分比：此值表示溢出条件，在此服务器指出队列溢出之前可以达到的队列长度大小的百分比。

         线程数增加：当检测到溢出条件时，将增加到执行队列中的线程数量。如果CPU和内存不是足够的高，尽量不要改变默认值“0”。因为Weblogic一旦增加后不会自动缩减，虽然最终可能确实起到了降低请求的作用，但在将来的运行中将影响程序的性能。

         最大线程数：为了防止创建过多的线程数量，可以通过设定最大的线程数进行控制。

在实际的应用场景中，应根据具体情况适当的调整以上参数。

c) 设定执行队列监测行为

Weblogic Server能够自动监测到当一个执行线程变为“阻塞”。变为“阻塞”状态的执行线程将无法完成当前的工作，也无法再执行新请求。如果执行队列中的所有执行线程都变为“阻塞”状态，Weblogic server可能改变状态为“警告”或“严重”状态。如果Weblogic server变为“严重”状态，可以通过Node Manager来自动关闭此服务器并重新启动它。具体请参考：Node Manager Capabilities文档。

通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 调整下可配置下面几项：

         阻塞线程最长时间：在此服务器将线程诊断为阻塞线程之前，线程必须连续工作的时间长度(秒)。默认情况下，WebLogic Server 认为线程在连续工作 600 秒后成为阻塞线程。

         阻塞线程计时器间隔：WebLogic Server 定期扫描线程以查看它们是否已经连续工作了 "阻塞线程最长时间" 字段中指定的时间长度的间隔时间(秒)。默认情况下，WebLogic Server 将此时间间隔设置为 600 秒。

5) 调优TCP连接缓存数；

WebLogic Server用Accept Backlog参数规定服务器向操作系统请求的队列大小，默认值为50。当系统重载负荷时,这个值可能过小,日志中报Connection Refused,导致有效连接请求遭到拒绝,此时可以提高Accept Backlog 25%直到连接拒绝错误消失。对于Portal类型的应用,默认值往往是不够的。Login Timeout和SSL Login Timeout参数表示普通连接和SSL连接的超时时间,如果客户连接被服务器中断或者SSL容量大,可以尝试增加该值。

通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 调整下可配置“接受预备连接”。

6) 改变Java编译器；

标准的Java编译器是javac，但编译JSP servlets速度太慢，为了提高编译速度，可以使用sj或jikes编译器取代javac编译器。下面说说更改Java编译器：

通过启动管理控制台，在域（如：mydomain）> 服务器 > server实例（如：myserver）>配置 > 常规下改变Java 编译器，默认为javac。输入完整路径，如：c:\visualcafe31\bin\sj.exe。然后打开高级选项，在预规划到类路径填写编译 Java 代码时为 Java 编译器类路径预规划的选项，如：BEA_HOME\jdk141_02\jre\lib\rt.jar。

7) 使用Webogic Server集群提高性能；

具体关于如何配置Weblogic集群，我就不细说了。详情可参考：Introduction to WebLogic Server Clustering。

8) Weblogic EJB调优

由于EJB2.0已经很少项目在用了，EJB3.0再成熟一点，我再补充这一部分吧！

9) JDBC应用调优

JDBC Connection Pool的调优受制于WebLogic Server线程数的设置和数据库进程数,游标的大小。通常我们在一个线程中使用一个连接,所以连接数并不是越多越好,为避免两边的资源消耗，建议设置连接池的最大值等于或者略小于线程数。同时为了减少新建连接的开销,将最小值和最大值设为一致。

增加Statement Cache Size对于大量使用PreparedStatement对象的应用程序很有帮助,WebLogic能够为每一个连接缓存这些对象,此值默认为10。在保证数据库游标大小足够的前提下,可以根据需要提高Statement Cache Size。比如当你设置连接数为25,Cache Size为10时,数据库可能需要打开25*10=250个游标。不幸的是,当遇到与PreparedStatement Cache有关的应用程序错误时,你需要将Cache Size设置为0。

尽管JDBC Connection Pool提供了很多高级参数,在开发模式下比较有用,但大部分在生产环境下不需调整。这里建议最好不要设置测试表, 同时Test Reserved Connections和Test Released Connections也无需勾上。 当然如果你的数据库不稳定,时断时续,你就可能需要上述的参数打开。

最后提一下驱动程序类型的选择,以Oracle为例,Oracle提供thin驱动和oci驱动,从性能上来讲,oci驱动强于thin驱动,特别是大数据量的操作。但在简单的数据库操作中,性能相差不大,随着thin驱动的不断改进,这一弱势将得到弥补。而thin驱动的移植性明显强于oci驱动。所以在通常情况下建议使用thin驱动。而最新驱动器由于WebLogic server/bin目录下的类包可能不是最新的,请以Oracle网站为准: http://www.oracle.com/technology/software/tech/java/sqlj_jdbc/htdocs/jdbc9201.html。

10) JSP调优

         设置jsp-param pageCheckSeconds=-1；

         设置serlet-reload-check=-1或ServletReloadCheckSecs=-1；

         设置jsp-param precompile=true，关闭JSP预编译选项。

Bruce Tate
总裁, J2Life, LLC
2005 年 5 月 30 日

轻量级开发是一个很大的主题，开发人员经常提到这个术语，但却很难讲明它的意思。本文是一系列讲述轻量级开发的文章中的首篇，介绍了该技术背后的核心原则及原理。

1990 年，我发现了白水漂流并深深爱上了它。我们哪怕是经过最小的湍流，都会留一个人在湍流尾部，两个人在岸边用绳索拽着。我们认为这可以防止任何糟糕的事情发生。虽然看起来一切尽在掌握，只是有些不太实际。我们还学会了从船舱观察普通的湍流，并设法互相协作。对于大多数危险的湍流，我们花费了更多的时间来保障安全，但是只有少数情况下，这些措施才起到重大的作用。

在漂流过程中，使用一种起源于东南部湍急河流的轻量级策略，为我节省了时间，使我可以划得更远，玩得更开心，而无需过多考虑安全问题。在业务领域，轻量级开发让您可以按时完工，积极响应客户，从而节省时间和金钱。

在本系列的文章中，我关注于轻量级开发（曾经有太多含义的术语）的基础。本篇文章作为第一篇，为读者打好基础，同时对轻量级开发做出定义。后面的文章由浅入深地讲述从过程到原则最后到工具的知识。我也将在更高的级别上关注原理和架构的实现，并且提供具体实现的代码。

本系列面向没有经过太多轻量级开发的读者。如果您已使用了两年的 Spring 轻量级容器和敏捷过程，您可能会收获更多。如果您在传统的开发过程中使用 Enterprise JavaBeans™（EJB），但想要转向轻量级开发，那么本系列就是为您准备的。

我更多地是想在这场席卷整个 Java™ 技术社区的潮流中，做一些自己的贡献。轻量级 这个噱头为诸如 Spring 和 Pico 这样的容器增添了几分优雅。并且，一些源自轻量级过程的技术，如自动化单元测试，现在也渗透到了很多开发工作室中。

戳穿针对轻量级开发的谣言
“轻量级开发”通常与一套开发方法、框架和设计原理一起使用。

• 轻量级方法 包括敏捷过程，例如极限编程（XP）和 Scrum。它们强调开发中测试第一，积极调动客户和重构。
• 轻量级框架 鼓励人们使用简单原始的 Java 对象（POJO）编程，而不是类似 EJB 的重量级面向组件模型。
• 轻量级设计模式 使您可以在对象和集成服务之间进行松散耦合，而无需艰苦地编写业务逻辑或领域模型。

当我们研究这些思想和技术时，您将会学到更多关于它们的知识。但是首先让我们戳穿一些谣言。

谣言：轻量级开发只是一种“玩具”技术。
许多开发工具，如 Microsoft® Visual Basic 或 PHP，它们通常不能驾驭或管理大型企业项目，因此得到了“玩具”的称号。像 Spring 和 Hebernate 这样的轻量级技术就常常因此而黯淡。实际上，大多数轻量级技术用于了企业开发，因为其他技术都使我们非常失望。Spring 框架就是作为代替 EJB 的一种轻量级技术。同样，XP 方法吸收改进了企业中的错误设置。我在获得 Jolt 大奖的 Better, Faster, Lighter Java 一书中，为大家讲述了有关成功部署在我的客户站点上的一些工具的信息，客户有一些是财富 500 强中的公司。轻量级技术在企业领域内，正在蓬勃发展着。

谣言：轻量级开发策略构建的是“玩具”。
也许您更倾向于相信轻量级开发只对构建“玩具”应用程序有益。而您的目标是精确地满足客户的需求。让我们首先明确一下：轻量级技术完全可以构建这种规模的应用程序。实际上，这种巨大的反差经常发生，因为只有简单、简洁、无状态的设计才能使基础设施更好地工作。

谣言：轻量级过程使您忽视规范。
在轻量级开发中，您需要认真地规划并与客户磋商需求。您必须构建严格的自动化单元测试，以优化重构。当放弃变更时，仍可以保持程序完整。而且，测试用例失败或变更引发错误时，自动化构建会通知您。轻量级开发必须比其他技术更加注意规范，但这种规范源于不同方面。

我认为这种开发风格超越了单一的技术或过程。如果您想轻松一些，那么需要选择使它易于工作的原则、过程和技术。

原则
该说的也说了，该做的也做了，您现在需要决定哪些需要重视，并据此制定决策。如果我觉得客户被误导或漠不关心，我通常会首先帮助他们建立核心原则。下面的列表是一个不错的起点：

• 争取简单性。这种观念应该渗入到您所有的工作中。您的过程应该刚好生成足够完成工作的工件。开发人员应该尽量使用最简单的方法解决问题。您的工具应该使您构建一个清晰、简洁的解决方案。
• 修补漏洞。许多开发方法可能不鼓励在过程中进行重构或变更，因为这些行为不直接用于产生客户代码。轻量级开发要求可以自由地修补太复杂或充斥 bug 的代码。您需要为它做出预算。
• 自动化单元测试。您应该优先编写测试用例。您可能还没有在测试第一的开发中成功过，但测试会间接给您带来重构代码的便利。我以后会进一步讲述：广泛的单元测试改善您的客户体验，并提高代码的设计水平，这是因为它强迫您解耦联系过于紧密的代码。
• 使用短开发周期并积极调动客户参与其中。许多顶级的软件工作室通过剔除不必要的工件来简化开发周期。如果您已经顺利得到客户的参与，那么很多的功能规范会变得越来越没必要。客户会很满意这种交互，并感激您的短周期开发，因为这稳步提高了客户的业务价值。

这些原则并不能完全包含您的技术抉择和开发过程，但它有利于您描述开发体验。如果经理也了解并遵循这些原则，开发人员就不至于做出无效技术选择，或者开发一些不必要的工件。确立原则后，就该规划一个有效过程了。

过程
紧凑、快速的开发过程通常从敏捷开发方法 当中得到灵感。然而，这些方法并不针对每个人。如果您有一个大型团队，并且没有实际访问客户或合适的代理人，那么传统方法更适合您一些。但多数项目都有小团队 —— 不超过 12 个人，他们可以充分访问客户，以灵活使用这种方法。通常，敏捷开发包括下列原则：

• 专注现场客户和代码，而不是其他设计技巧。您可以使用其他技巧，但只在它们对您确实有益的情况下。本过程不需要它。
• 简化您需要的文档。为了需要，宁可使用电子表格中的一行来描述，也不使用令人困惑的用例图。
• 只做足以完成工作的设计工作。不要对设计或性能过分忧心忡忡，使自己陷入绝境。
• 为了开发，努力进行简化并保证至少每天都集成您所构建的程序，必要时进行重构。
• 自动化测试。

即使您工作在传统的机构，您也可以利用已裁减的开发过程。技巧是推广原则 而不是方法。推广极限编程管理器 —— 或其他冠以极限 的东西，这可能会很艰难。但推广类似单元测试的原则通常更有意义。实际上，我的许多客户使用这种技术同敏捷开发过程一起为保守的机构服务，但他们的老板丝毫不知道有什么发生了改变。

用修辞手法描述一下这种技术。原则 是重拳出击的轻量级思想。过程是重量级的，实现起来将会很困难。

技术
我已经概述了大多数轻量级开发人员需要了解的设计原理，以及利用这些原理的重要开源技术。

依赖注入
最新一代容器称为轻量级容器，它们使用一个共同设计原理：依赖注入。 对这个简单思想来说，这是一个复杂的术语。依赖注入让您将对象和它所依赖的东西交给第三方。然后第三方创建所有对象并将它们绑在一起。比方说，称为 myDao 的数据访问对象需要一个称为 ds 的数据源。那么该容器会一同创建它们，并设置一个属性：

myDao = new Dao();
ds = new DataSource();
myDao.setDataSource(ds);

当然，不创建这种第三方汇编程序的话，您也可以使用框架来做其他附加的工作（如提供配置支持）。Spring 框架、Pico 和 HiveMind 就扮演了这个角色。其他像 JavaServer Faces(JSF) 框架也利用了依赖注入。

面向对象编程
使用面向对象编程（AOP），您可以编写通用的功能性模块（称为方面） —— 例如，日志、事务、安全或持久性。AOP 使您可以将这些方面联系到 POJO，然后指定一个时间点（如方法开始时或产生异常时）和另一个需要联系的方面。例如，您可能想要创建一个外观事务对象。您可以在调用方法时将 TransactionBegin 方面关联到外观方法。然后在产生异常时将 RollBack 方面关联到外观的异常。最后，在方法结束时将 Commit 方面关联到外观的方法。您在配置中完成这些工作，而不是通过编写代码。依靠这种能力，您可以创建一个简单的 POJO 事务、安全或远程访问。

您现在已经得到了关于 POJO 的声明性事务，这对企业应用程序非常有用。使用这些工具，您可以完全放弃 EJB，或者最小化它的作用。而这正是轻量级组件所要做的。

透明持久性
持久性也是建立在较简单的编程模型之上。透明持久性框架通过配置而不是编写代码，来使您为应用程序添加持久性。因为大多数应用程序是面向对象的，并且访问一个关系数据库，所以一些专家断言，我们最终将进入对象关系映射的时代。我目前发现的顶级持久性解决方案是 SolarMetric 的 Kodo JDO 和 Hibernate（参阅 参考资料）。在后面的文章中我将详细比较这些解决方案。其他轻量级解决方案，例如 iBATIS 和 Active Record 设计模式，根本不会试图进行对象关系映射。

结束语
在轻量级开发中，您基本上可以：

• 合并过程、技术和原理。
• 优先选择较简单的技术。
• 在一个稳固、轻量级的基础上，进行构建。
• 尽量争取最可能的透明性。
• 使用您可以利用的技术，如依赖注入和 AOP。

一定要明白，无论技术还是过程都不能完整定义轻量级开发。它是一个包罗万象的概念。伴随本系列的文章，您将看到对轻量级技术和原理的各种各样的讨论。我将首先关注开源框架，并着重讲述轻量级容器。后面的文章，我会讨论保守公司内的轻量级方法实现，甚至还有一些超越了 Java 技术的替代方案。我非常喜欢这个系列的文章，希望您也一样。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
  
• 阅读 Bruce Tate 和 Justin Gehtland 编写的 Better, Faster, Lighter Java 一书，此书更好地概述了轻量级开发。
  
• Bruce Tate 和 Justin Gehtland 编写的 Spring: A Developer's Notebook 一书可以帮您快速入门 Spring。
  
• 想了解更全面的 Spring 知识，请阅读 Rob Harrop 和 Jan Machacek 编写的 Pro Spring，以及 Craig Walls 和 Ryan Breidenbach 编写的 Spring in Action。
  
• developerWorks 题为“无需容器的对象关系映射”的文章为您展示了如何与 Hibernate 一起使用 Spring 持久性。
  
• 阅读 developerWorks 关于 AOP 的一篇文章“AOP@Work: AOP 工具比较，第 1 部分”，它是提供更佳透明性的轻量级技术。
  
• 访问 developerWorks 的开源专区 获取大量 how-to 信息、工具和项目更新，以帮助您使用开源技术进行开发，并学会如何与 IBM 产品一起使用。
  
• 使用 IBM 试用软件 改进您的下一个开源开发项目，这些软件可以通过下载或购买 DVD 获得。
  
• 在 Developer Bookstore 的开源专区，可以找到数百本 开源主题的打折书籍。
  
• 通过参与 developerWorks blog 加入 developerWorks 社区。