Windows 2003 Server的TOMCAT的内存池配置问题

最近在Windows 2003 Server上安装Atlassian的Confluence时，发现Conflucence经常引起Tomcat 100%占用计算机资源，经查资料发现是TOMCAT(ver5.5)的Java虚拟机内存配置问题，其缺省配置为128m，对于一些大量页面访问、会占用大量资源的应用，容易导致宕机。

解决方案：增加Tomcat的JVM的Maximum memory pool的值，可根据具体机器的配置增加，在我的1G的机器上将其改为512M后，系统运行正常。

Step:

1. 双击托盘上的Apache Tomcat图标(如果未出现，请先选择程序菜单Apache Tomcat -> Moniter Tomcat), 打开Tomcat Monitor的属性页面。


2. 选择Java属性页。


3. 设置Initial memory pool和Maximum memory pool的值。


4. 确定。重新启动即可。

Occam's Razor(奥卡姆剃刀)——以及软件设计中关于"简单"的相关性话题

奥卡姆剃刀（Occam's Razor, Ockham's Razor）是由14世纪逻辑学家奥卡姆的威廉提出的一个原理。奥卡姆（Ockham）在英格兰的萨里郡，那是他出生的地方（后人习惯称之为 "William of Occam"）。这个原理称为"如无必要，勿增实体"：

Entities should not be multiplied unnecessarily

此外，还有更多的关于"奥卡姆剃刀"原理的阐释：

解释任何事情都不应当增加不必要的实体数。One should not increase, beyond what is necessary, the number of entities required to explain anything.

如果某一原因既真又足以解释自然事物的特性，则我们不应当接受比这更多的原因。 We are to admit no more causes of natural things than such as are both true and sufficient to explain their appearances.(Isaac Newton)

当你有两个处于竞争地位的理论能得出同样的结论，那么简单的那个更好。When you have two competing theories which make exactly the same predictions, the one that is simpler is the better.

威廉使用这个原理证明了许多结论，包括“通过思辨不能得出上帝存在的结论”。这使他不受罗马教皇的欢迎[1]。在科学领域，“奥卡姆剃刀”作为一种“parsimony of explanations”的原则，具有很大的影响，爱因斯坦、霍金都明确地表示使用了这条法则来进行阐释和分析。对于商业以及生活中，作为一种简单的实用主义原则同样备受推崇，这方面的介绍可以参见附录部分的资料[2]。

在软件开发中，使用"Occam's Razor"原理是判断过度设计的一条好的法则，我们常常为了不必要的灵活性而使系统变得复杂。另一种我常见到的情况是在进行Unit Test Case设计时，很多人并非依据代码覆盖和逻辑覆盖的原则，而是简单的数据量增加或者写多处同一种情况的测试代码，测试者一厢情愿的认为这会帮助发现更多的Bug，但这只会让人难以理解测试设计的思路。

两个关于"简单"的相关性话题：

Simple is beauty

我看一个代码设计的好不好，最初的判断通常来自于直觉，它的基础就是"Simple is beauty"。之所有说是自觉，是因为"简单"并没有一个客观的标准，依靠提供者的信息和阅读者的感觉。如果从设计中我能够捕获设计者的思想，获得设计的关键抽象，在头脑中可以形成很清楚的结构图，它们的每一部分职责清楚，个体的概念明确，之间的联系也容易理解，这会给看的人一种愉悦的感觉。当然，好的设计有很多的因素，但这是最基础的"特质"[3]。而如果情况相反，则通常都是不好的设计，意味着还没有搞清楚事物本身的特征和之间联系，或者缺乏抽象和描述能力。自然界和社会的客观规律总是有章可循，但却呈现出复杂的表象，需要设计者具有很强的抽象能力来提取事物的"本质"，简化这种复杂度。人的记忆力是有限的，很难理解过多概念的系统，但人却具有很强的逻辑思维能力，善于理解抽象特征，所以，如果一个设计提供的是表象的复杂度，通常很难理解，也可能意味着没有建立好的抽象。

简单并非简陋

上面提到的情况其实指的是一个系统的设计超过了它不该具备的复杂性，也就是说我们完全可能满足同样的要求下，通过分析抽象获得更简单的设计。但正如Fred Brooks所说，有的事物是本质复杂的[4]。如果一个系统打算完成10项功能，那只完成了其中5项功能的系统相比较完成了全部功能系统要简单。

本质复杂度有时候很难通过设计达到某一种简化，而常常需要通过减少一些功能来达到简单的目的。一项功能的存在总是有其价值的，如果没有原则的简化，也许系统的设计是简单了，但因为缺少了必要的功能可能使系统无法使用或极其难以使用，简而言之，"简单并非简陋"。

要简化系统的本质复杂性，需要考虑系统的使用价值和其它制约的平衡，比如时间、财务等资源性因素，以及系统设计复杂性。系统可以完成的功能就像巫师的口袋，是看不见底的，有时候为了努力保持系统设计的简单，删减一些不必要的功能是明智的。

关于这方面，我的另一个经验原则是：

当一个功能的价值没有明确时，尽量选择简单的方案。

正如人们说的，“软件开发是权衡的艺术”，要敢于舍弃，更要善于舍弃。

------
[1].引自 《What is Occam's Razor? 》 英文版, "三思科学"上的中文版:奥卡姆剃刀(Phil Gibbs 著,杉原广 补充,柯南　译)
[2].《奥卡姆剃刀：影响全球精英命运的思维法则》,作者：罗耶 编译，中国民航出版社
[3].参见C.Alexzander的"建筑的永恒之道"，Alexzander认为好的建筑都具有某种无名"特质"。
[4].参见Fred Brooks的 "No Silver Bullet:Essence and Accidents of Software Engineering"

See Also
Occam's Razor On Principia Cybernetica Web

关于一个工作流项目的简略评估报告

原文:2003/2/13
修订:2004/3/17

这并不是一次正式的评估，而是一种访谈性的非正式评估(当时称之为交流)。事情的来由是这样的，公司有一个项目组承接了国家的863项目开发一个工作流产品，部门的领导对这个东西有较高的期望，但并没有提供与这种期望相应的支持。项目的结果并不太理想，因此部门领导对这个项目组非常不满，另一方面开发小组经常加班，成员因为得不到认可，士气低落。我当时并不在这个项目组中，但我觉得这个项目的不成功（从领导的期望来说）是有很多不属于项目组的原因，作为公司的一名资深的技术人员，我希望能够做一次简单的评估，以帮助领导能够清楚地了解项目的现状、形成的原因，好的和不好的地方，能够公平的看待项目组的努力（希望如此）。但最后这份报告并没有提交，开发室的主管有一些担心，而我也尊重他的意见，只在小组成员中进行了交流。

本文的主题涉及到公司进行863项目的一些内容，希望不会成为人们抨击公司和863项目本身的工具，我的目的是提供一些关于失败的教训或值得借鉴的经验。

原文序：2月11号下午，工作流项目组成员、部门主管XXX和我进行了一次比较长的关于工作流项目情况的总结性交流，以下是我通过交流对项目的一些认识和看法，从项目的最终结果的状态、项目的目标、项目开发过程中的好的和需要改进的地方等多个方面进行了分析。

项目背景

项目来源于公司申报的国家863项目。工作流项目于2002年4月启动，12月份基本结束，但还未通过国家验收。

项目成果状态

项目并未进行同类商业化产品的比较，主要目的是通过国家的验收，因此产品仅停留于技术原型状态。项目组选取了一些典型的应用案例，并基于原来在群件系统上的工作经验和WfMC（工作流管理联盟）的标准制定了需求，开发了可运行的基于J2EE平台的模型，其中包括了工作流引擎、建模工具以及一些示例，具备了应用开发包(SDK)的基本内容。

产品化能力

鉴于时间和本身的原因，我们并没有真正进行产品的技术性测试评估，而是根据项目的一些信息来了解它的成果。相对于市面上可使用的主流服务器(如BEA/IBM)厂商产品和第三方产品以及开放源码产品来说，在实用性、成熟度、同其它技术和环境的整合度（如安全）、开发支持产品（文档、指南等）等方面还有较大的差距，毕竟这些产品的开发时间较长，并具有良好的开发基础。总的说来，离产品化还有很大的差距，有些原因不可忽略：

• 项目组具有群件平台（办公）协作的工作流方面较深厚的背景，但对业务流程协作相关的工作流仍然缺乏对应用场景的了解，公司的项目也没有类似需求提炼出来，项目组缺乏使用场景的引导，难以产生有效、完善的产品需求。
• 原来的项目目标是通过国家的863验收，而863验收向来比较形式化，公司也没有明确的在产品的实用化价值上的诱导。
• 有效的开发时间和人力太少，不可能产生商业化或可实用化的产品。通用化产品必须具有相当的成熟度后才可使用，否则大量的问题会是使用者失去信心，并让项目组陷于铺天盖地的维护工作中。这个问题下面会有描述。

项目的主要问题

经过交流发现项目存在以下现象：

高层目标模糊

公司在处理863项目没有自己的立场，为863项目而作863项目，没有考虑自己的发展方向，带来的结果是公司的高层领导并不关心以863计划为基础的项目，只有项目部才关心，因为他们需要对验收负责。到公司和部门来说，这些项目大多与公司的业务方向和基础背景不同，这带来了两个不利的方面，一是项目的目标不具有实用性，二是缺乏开发的基础。

工作流项目原来的目标据项目组说上级领导的意见是：

• 完成863项目
• 培养J2EE人员

因此项目并不来自于自身的需求，而这样模糊的高层目标难以指导项目组完成具有真正可用性和市场化的产品。当然这些并不是在《前景》文档中反映出来的，然而是事实上的指导目标。

缺乏需求和应用场景获取渠道.

公司在过去企业应用的开发上虽然有一定的业务协作工作流的应用场景和办公协作应用的开发经验和理论基础，开发时对需求的处理也因无法找到好的需求获取渠道显得效果不是特别好，而且用例我觉得在描述这种需求上还很有局限性，无法体现应用价值和应用场景，应当增加其他的需求描述方式，当然需求渠道和应用场景是最主要的。

项目组制定了计划，但计划经常被打断，并造成计划失效

被外界干扰来源于几个方面：

• 人员调整。项目从初期到后期，人员一半以上被调换，无法保持一个一致的设计思想，特别是9月前后，后来的人需要重复以前的工作，这种人员的变化，是项目有效工作时间减少的主要原因。9月是项目组的编码实现阶段，虽然计划仍然在执行，但事实上受到了人员变化的影响，理解/废除/改进原来设计，增加了工作量，在按时完成的要求下，项目组只有缩减需求。
• 被抽调从事项目外的工作。在9月以前，项目组成员经常被抽调去进行其他工作，例如编写标书，项目成员认为在4月-9月之间基本上没有进行太多的工作，这段时间内的有效工作是需求和高层的设计。
• 需求的问题也导致了在计划被打断时调整的随意性。在整个开发过程中项目人员变动较大，受外界影响也很大，出现冲突时项目选择了削减需求的策略。

计划存在阶段，但成员对阶段的结束点和完成标志感觉不清楚

因为工作流项目不是一个面向直接用户的产品，而是一个面向应用开发的基础服务产品，因此没有很明确的像MIS项目的交互式功能类型的需求，项目组在需求完成后无法获得对用户价值或“可视化”结果的主观感觉。

在处理这种类型项目上，以后的项目应该注意这点。我建议采用“领航者”项目来解决这个问题，即项目需求确定一个应用项目，可以是外部的，也可以是自己根据应用场景建立起来的，关于这个问题，以后的项目可以参考《软件架构：组织原则与模式》一书。这主要是让应用来驱动项目，并让项目组感到每一个完成点带来的价值。

项目的有效开发时间短

前面已经提到9月以前项目的工作基本上提留在需求和部分的前期设计上，9月是项目的主要开发期，10月份项目成员有部分被抽调出去，10-11月集中在引擎的完善和增加外围部件。12后项目为了准备结项验收基本上结束了开发。基本上看来，项目整个的有效开发工作量约为5月*5人=25人.月，这对于像J2EE工作流应用这类产品来说太少了。

值得保持的地方

• 每周的周例会，短小，但起到了了解计划、解决问题的作用。实际上周例会起到了项目周计划的作用。
• 单元测试成为有效的检测手段。项目组采用JUnit的测试技术，对错误的查找、提高开发质量起到了很大的重要，另外在没有其它检测手段的情况下，可以在一定程度上反映任务的完成。建议以后在项目中推广XUnit测试技术（Java的JUnit,C#的NUnit/csUnit等）。

需要改进的地方

RUP过程组织不成功

虽然项目是按照RUP方式来组织项目，但并不成功。阶段的划分比较机械，迭代的概念并不完整，阶段的划分和迭代的周期显得不合理，这也跟项目组的计划受外界影响可能有直接关系。从目前看，RUP并没有在我们内部真正使用好，RUP过于庞大复杂，建议以后的项目要慎重，不要机械的使用RUP。

公司内的工程管理活动并没有给项目组带来实际的价值

SQA活动被要求，但并没有太多实际价值(改进活动)。这些活动包括组织（SQA部门）对项目活动和文档的评审，缺少对项目组真正有帮助价值的管理，这些是与组织的过程管理成熟度是有关的，在不成熟的组织，容易成为形式，并带来负面影响。

建立架构组负责项目的关键决策

项目组没有一个明确的架构人员或架构组，以至于在一些项目项目的整体的构架决定上无法及时决策。在关键需求的定义、应用的验证和目录数据库技术引入等决定上都有影响。但对于每一部分具体的逻辑设计，构架组的作用并不明显，因此这里的构架组主要担任一种决策的职责。

但项目组同时也建立了与系统结构一致的组织：引擎组、建模工具组、原型组，这种结构应当是合理的，符合系统的特征，只是在进行的过程中，3个小组的节奏不太一致，难以形成一个整体的感觉，如果存在构架师或构架组也可能使他们更容易形成一个整体。

项目需要就总体计划保持一致

同时也发现项目组成员对整体的计划没有很好的理解。虽然项目经理公布了进度，但因为总体计划经常变化，以至于在成员心中没有了权威性，这一点也可以说与需求的变化和外部的干扰有很大的关系。当然项目组如果能够控制变更的节奏（如两周或一月才基线化变更，而不是一有变化就引入给其他成员）和更有效的方式来反映进度（如进度图表、测试通过率等形式化手段），也可能会有改进。

　

说明: 本文的主要目的仅为帮助项目成员和外部人员通过项目的总结获得有价值的经验，了解项目的情况，并不证明项目本身的成功或失败。内容来自于交流获得的信息，虽然力求真实，但仍然带有很多个人的判断，需要注意。