浅谈J2EE开发 之 高效的方法

上次说到了J2EE开发中稳定的代价，也就是性能下降以及开发者的学习成本以及学习曲线。今天来说说J2EE开发中的高效。要理解高效，首先要明白高效是什么意思，只有在同一个大前提下才能明白在讨论什么，不然的话，南辕北辙了。

首先，高效是建立在稳定的基础上的，其次，高效是在符合业务逻辑的基础上，最后，高效不仅仅体现在程序跑的快上。

第一位的，自然是一些最基本的开发技巧。比如说，用StringBuffer，不要频繁开关数据库连接。这些东西在任何一本书上都可以查到。本质上是减少CPU指令，从而减少运行耗时。这里提一句，在JDK5及以上的版本里，String类用加法连接的话，除了不好看以外，已经没什么问题了。Sun的编译器会编译成StringBuilder实现。这个东西是StringBuffer的线程不安全版本。换言之，如果同时有两条指令操作同一个StringBuilder的实例，那就要看运气才知道结果了。线程安全，就慢，因为同步。线程不安全，就快，因为不同步。至于要同步还是不同步，并不是一概而论的。

同步或者不同步，本身是针对方法或者对象说的，也就是所谓的加锁。这里不讨论各种锁的实现，比如自旋锁之类。那么，何时用同步，何时用不同步呢？

要回答这个问题，首先要明白同步和不同步的用途，也就是说，什么时候用同步，什么时候不用同步。首先从道理上来说，对同一个物体，对它的操作应该是排队进行的。也就是说，先进行操作一，再进行操作二。换一个说法就是，操作一没有宣告自己完成之前，操作二不得进行行动，这个就是同步。同步的好处很明显，能避免很多由于同时访问同一个对象带来的麻烦。比如操作一会从篮子里拿出来一个鸡蛋，操作二要对篮子里的鸡蛋计数。如果两者相差很短，短到手刚伸进篮子里，还没拿出来的时候就开始计数了，那么最终结果就是匪夷所思的。等两个操作都结束了，鸡蛋明明少了一个了，可是计数的人却说，我明明数的要多一个。

这就是不同步带来的问题。

从上面的例子看起来，貌似什么时候都要同步才行，一旦不同步就要冒风险。其实这句话从某种意义上来说是对的，不同步的确是有风险的。但是，这不是绝对的，不是百分之一百存在的。如果异步有风险，那为什么没有被明令禁止？这就说明异步还是有一定的用武之地的。那么什么时候可以使用异步操作呢？

不会改变物体状态的操作可以异步进行。比如说，一个操作是称重量，一个操作是数个数。我们假设鸡蛋只有一层没有重叠，而且数鸡蛋的人不近视(- -#)，那你俩一起干活好了啊。你数鸡蛋就数呗，称重量的你就称呗。因为称完重量不需要拿一个出来煮了吃，数鸡蛋的也不会数完了摸一个回家做荷包蛋，操作前操作后总数都不变，那么就一起来好了。

切换到实际开发场景里的话，增删改查里，查询可以异步操作，也就是不等待上一个查询完，下一个查询即可跟上。但是如果牵涉到其他三个操作，那么必须同步。因为不管是INSERT还是UPDATE还是DELETE，都会有很大可能改变数据库记录的状态。实际上，我上面说的这些内容在数据库里有个专用名词，叫隔离级别，有兴趣的话可以去查查看，深入了解一下。如果在开发中能遵守上述条款的话，会减少很多莫名其妙的问题。

第二位就要轮到开发技能以外的技能了。也就是用户好用。

一个简单的例子。用户去CDM上存钱。银行A的方案是，用户每一步操作都要输入密码，存入卡里之前要用户确认三遍数目，最后存完了还要放歌给用户听。银行B的方案是第一步输入密码，然后存入卡里之前让用户确认一次总数，最后使用简短的声音提示用户操作完成。

也许您会笑，哪有这么罗嗦的银行CDM啊。呵呵，是的，这个场景是我夸张出来的，的确不会有人设计这种系统。但是话说回来，在很多专业系统的研发过程中，专业人员和开发人员往往会陷入两个很奇妙的问题里。专业人员对业务无比熟练，基本上是闭着眼睛都可以说出来。开发人员是对编程无比熟练，技巧无所不用其极。但是还有一方面，他们对于对方的领域是陌生的，于是乎，专业人员往往会乱指挥开发人员干活，而开发人员设计的操作步骤也会搞的专业人员头晕脑胀。系统越专业越阳春白雪，这种问题越多越普遍，因为实在是太难懂了。

我们可以试想一下，让我们去开发宇宙飞船的管理系统，却不给我们足够的专业培训，那么结果会是什么？要么做出来不能用，要么做出来勉强能用了，NASA的人会吐血而亡，因为实在是太繁琐了，和平常的工作步骤完全不是一回事啊。也许平时工作，大家总结出来一些习惯做法和高效的做法，只需要三步就可以解决问题，开发人员不知道，根据书本上的东西来，一下子变成了三十步乃至三百步，那么这是不是也造成了系统的效能低下呢？无论如何，操作三个步骤的耗时都比操作六个步骤的耗时少吧？

再看回上面的CDM的例子，估计银行B的客户钱存完，饭都吃完了，银行A的客户才刚存完钱吧。那么，你代码写的再好，又有什么用？

最后一点，也是最不容易做到的，就是架构上的调整。这一点牵涉到非常多的环节，也不是一个小程序员能够完成和控制的。所以，这里仅仅做一些简单的说明，具体内容等到后面会有具体章节来讲的。首先要避免表结构设计的不合理，比如说明明可以放在一个表里的数据，结果给丢到十七八个表里去了，那只好SELECT XXX LEFT JOIN XXX，这肯定不行。还有就是不要把需要经常通讯的程序放在不同的网段里，要知道通过路由的层层盘剥以后，数据包丢包率是非常高的，尽量放在一个路由器下甚至是一台机器上吧。

关于高效的问题，先说这么多吧。最近比较忙，所以更新有点慢，不要着急哦。下一次会谈到易用这个问题。