给一个很能吃的人 上三份饺子，三份粥，三只烤乳猪，他会怎么选择？ 1. 轮换式：吃盘饺子，喝碗粥，吃只猪 –> 吃个饺子，喝碗粥，吃只猪 –> 吃个饺子，喝碗粥，吃只猪 2. 流水线式： 吃三盘饺子 –> 吃三碗粥 –> 吃三只猪 如果我们定义： 一盘饺子 +一碗 粥 + 一只烤猪 = 一份套餐 那么，如果食客选择第一种吃法，那它就吃了三份套餐，从任务定义的角度，我们的设计可以更简洁 如果他选择第二种吃法，设计上不那么简明了，但效率可能会好很多。因为吃第一盘饺子的器皿可以马上用来吃第二盘、第三盘，吃粥的碗也是一样，整顿饭一共要“端碗/盘”三次。而对第一种吃法而言，他吃完第一盘饺子后，要换用粥碗去吃第一碗粥，然后用换另一种食器去吃猪，接着又换回盘来吃饺子…… 整顿饭它要“端碗/盘”九次 或许你认为我在说废话，根本没啥实际。但如果把上面的 吃东西 替换为 下载东西， 把 端/放碗 换成 建立/释放 网络连接， 你可能就不会这样想了
标题可能不好理解，先举一个例子。 在一个会议室预订系统里，有这样一条业务规则： 当收到一个订单时， if 当天是星期三 then 立即借出 else 交给管理员手动审批 我们把这个规则直接实现在业务方法里，即 class 预订服务{ void 处理订单(){ if(当天是星期三) 借出(); else 交给管理员手动审批; } void 借出(){ //to do } } 假设系统运行一段时间后，这个业务规则突然被取消了，那就得让开发人员修改这部分代码 又假设业务规则不变，按照这个规则，一个订单被批准。但是由于紧急情况，管理员不得不否决了该订单。可是申请者不知趣，又重新提交该订单、结果订单又被批准，管理员又得强行否决…… 所以我们换一个办法。建立一个机器人类，名叫“机器人管理员”。它定时地扫描订单队列，一旦发现有了新订单就立即按照上面所说的业务规则进行处理。 如 class 机器人管理员 extends 管理员 implements Runnable{ void …
《软件需求》，Karl E.Wiegers著 1 总论 一定要编写需求文档 需求的三个层次（从高到低）： 1. 业务需求，最高层次的目标要求 2. 用户需求，Use Case 3. 功能需求，必须实现的软件功能 优秀需求的特性： 1. 完整性 2. 正确性，一致性 3. 可行性 4. 必要性 5. 划分优先级 6. 无二义性 7. 可验证性（根据需求能否写出测试用例） 8. 可跟踪性 需求工程的结构： 1. 需求开发，分为四个步骤 a) 问题获取(elicitation) b) 分析 c) 编写规格说明 d) 验证(评审，编制测试用例) 2. 需求管理，即需求追踪、变更控制等 需求文档是用户和开发组之间的契约，对双方同时形成约束 2 需求开发 建议需求开发过程： 1. 定义项目的视图和范围 2. 确定用户类 3. 在每个用户类中确定适当的代表 4. 确定需求决策者和他们的决策过程 …
原需求： 如果A， 则 不 杀人；否则，杀人. 新需求： 如果B=1， 杀一次人； 如果B=2， 杀两次人； … 如果B=N, 杀N次人； 原需求只区分了 是 和 非， 没有量化，如果量化，也只是 0 和 1. 所以，当客户以 是 和 非的 模式提出需求时， 我们要主动地问他这个东西有没有可能拓展为 0,1….N的模式。如果代价不大的话，就算客户当时认为 是/非 模式够用， 我们的系统最好也要实现为后一种模式。因为前一种模式蕴涵了后一种（前一种是后一种的特殊情况），反之不然
人都是懒的 让用户少动一下老鼠 他会很感激你 的
http://www.ha999.com/ha/hasolution.htm 双机热备的实现模式 － 基于共享存储与纯软件方式 双机热备有两种实现模式，一种是基于共享的存储设备的方式，另一种是没有共享的存储设备的方式，一般称为纯软件方式。 基于存储共享的双机热备是双机热备的最标准方案。 对于这种方式，采用两台（或多台，参见：双机与集群的异同）服务器，使用共享的存储设备（磁盘阵列柜或存储区域网SAN）。两台服务器可以采用互备、主从、并行等不同的方式。在工作过程中，两台服务器将以一个虚拟的IP地址对外提供服务，依工作方式的不同，将服务请求发送给其中一台服务器承担。同时，服务器通过心跳线(目前往往采用建立私有网络的方式)侦测另一台服务器的工作状况。当一台服务器出现故障时，另一台服务器根据心跳侦测的情况做出判断，并进行切换，接管服务。对于用户而言，这一过程是全自动的，在很短时间内完成，从而对业务不会造成影响。由于使用共享的存储设备，因此两台服务器使用的实际上是一样的数据，由双机或集群软件对其进行管理。 (典型的双机热备产品，参见：LanderCluster集群软件) 对于纯软件的方式，则是通过支持镜像的双机软件，将数据可以实时复制到另一台服务器上，这样同样的数据就在两台服务器上各存在一份，如果一台服务器出现故障，可以及时切换到另一台服务器。 对于这种方式的深入分析，请参见：纯软件方式的双机热备方案深入分析 纯软件方式还有另外一种情况，即服务器只是提供应用服务，而并不保存数据（比如只进行某些计算，做为应用服务器使用）。这种情况下同样也不需要使用共享的存储设备，而可以直接使用双机或集群软件即可。但这种情况其实与镜像无关，只不过是标准的双机热备的一种小的变化。
摘自《withou ejb》 1.不必要的数据库访问 2.在JAVA对象和XML文档之间进行过度的转换 3.过多地进行远程调用
Runtime lRuntime = Runtime.getRuntime(); out.println("Free Memory: "+lRuntime.freeMemory()/1024/1024+"M"); //已分配的空间中未被使用的部分 out.println("Max Memory: "+lRuntime.maxMemory()/1024/1024+"M"); //最大可分配的空间 out.println("Total Memory: "+lRuntime.totalMemory()/1024/1024+"M"); //已分配的空间
按我个人的体会，连接个数太小会导致赤贫和暴富，个数太大会导致共同贫穷。 连接个数太小 => 只有部分请求能得到满足，而且连接少，应用服务器的CPU线程也少，应用服务器的响应就快，这些请求就能得到很好的满足，因此它们“暴富”；其他的请求都被冷漠的一口拒绝，它们陷入“赤贫” 连接个数太大 => 多数请求都能得到满足，但响应时间普遍较长 => 共同贫穷
Load Testing： 不断增加压力，直到超出系统负载。此时的压力，即代表了系统处理能力的极限。比如，我们不断增加并发用户数，当用户数达到100个时，发现事务的响应时间刚好超过了我们要求的10秒，那么我们系统可承受的并发数就是100。 性能调优时往往需要这种测试 Stress Testing：使系统处于饱和状态下，然后观察此时系统的表现。这种测试一般用于观察稳定性：系统在满荷时能否稳定地提供服务