转发同事在例会后对技术问题的反思和对做事方式的改进思考

序：

周五是某项目组内部例行周会时间，上周同事L将他在会后自己对技术问题的思考和对做事方式的改进想法发给了项目组，抄送给我。看完文章后，感触颇深，L也是以往在我认识中也是一个很技术化的同事，通过这段时间的锻炼和挫折，已经认识到执行力的重要性，而强调执行力，更加需要人有思维上的改变。

L的反思和自我改进，我看出了他的良苦用心，从正文中可以看到L的苦闷，有不被理解的呐喊，希望他的项目各位同事能够认识到、体会到。人就是这样，只有将内心的原有一些抱持的观点放下，腾出空间，才有可能去容纳、接受其他观点。学会站在不同的角度去思考问题，站在对立面去思考，才有了这样的反思。如何看待过去，将决定了如何看待未来！现将内容转发如下。

 

邮件正文：（注：正文中的黑体部分是转贴时标记的）

以下是本次例会上谈到数据源解决方案时说到的一些东西，算是个人的一些思考，但是很多问题其实还没有答案，需要大家帮忙一起找到答案，大家也可以提出自己的看法，我嫩有很多需要总结的，很多需要去“善后”的工作。除了会议上提到的6点，我另外做了一些补充说明：

1. oralce10g的驱动和dpcp1.2.1连接池是否真的有冲突，如果有，是什么原因导致连接的泄漏跟驱动相关，按照通常的理解，连接不是应该由连接池管理吗？我们在10月份上线前已经更换了oracle驱动到10g，使用的也是dbcp1.2.1，为什么在那3天的时间内，没有出现连接池耗尽的问题？或者说我们当时有没有想清楚，我们系统在上线后频繁的连接池耗尽的情况真的“仅仅”是因为oracle10g的驱动和dbcp1.2.1不兼容吗？没有想清楚的情况下，为什么第一个想到的是别人的连接池有问题，别人的驱动有问题，自己的代码没有问题，更换驱动，更换连接池，然后继续有问题？
2. weblogic的数据源，使用oracle驱动时，马上链接耗尽到底原因是什么，为什么别的项目从来没有出现过，另外，使用bea版本的oracle驱动，我们目前似乎确实解决了连接耗尽的问题，但是是否存在潜在的功能性或者非功能性的问题？
3. 数据库连接驱动一定要和服务端版本最好保持一致，也有可能有特殊原因导致一致的驱动仍然存在问题。但是我们是应该对这存在的个别问题特殊处理呢，还是冒着种种潜在的不兼容风险去更换驱动版本？我们这次从头到尾都没有用过和服务器一致的驱动版本，那是我曾经被客户一再质疑我们的解决方案时最无语的时刻。
4. dbcp的数据源有一个功能可以关闭取出池，并且超时没有使用的链接，主动关闭，但是为什么weblogic的数据源没有这样的功能？而且，代码层面存在一些连接泄漏的问题，为什么在之前的应用中没有使用此配置，也没有像目前这样频繁出现连接泄漏的问题？
5. 通过rmi的协议，使用远程连接创建的对象，当连接中断处理而没有即时的销毁对象时，这些对象不会自己销毁而一直占用系统资源，当这种情况发生时，我们的内存耗尽导致内存溢出，这是我们当时对内存溢出的一部分猜想，并且以heap内存的分析数据为基础跟客户进行了解释，可是我们现在将数据源rmi的访问方式已经废弃了，在星期三下午半小时内出现了3个节点共计4G内存溢出，如果不是我们及时发现并及时处理，我应该如何向客户解释，我想过这个问题，并且想的心惊胆颤直冒冷汗。所以我们该行动了，不要逃避自己的问题了，责任都推给了BEA。
6. 目前通过weblogic的console的数据源监控可以发现程序依然存在没有关闭的链接的现象，有导致连接耗尽的危险。一方面在tomcat上我们也需要类似的机制能够监控数据源的健康状态，一方面需要通过一些监控手段找到数据库连接泄漏的操作点并即时修复相关代码缺陷。我们之前是有尝试做这个工作，但是当时此程序上线时直接导致了内存溢出的频繁发生。虽然引出了新的问题，但是我认为DY还是给我们提供了很好的问题解决思路，还是要对DY表示感谢，毕竟当时很多的连接泄漏点都是被此程序找到的，希望DY继续帮忙完善，可以作为通用的组件广泛应用。

以上是会议上提到的若干点我们要思考的问题，另外，对与我们做事的方式，也有几点需要改进的：

1. 当时虽然很紧急，需要迅速的出解决方案，但是我们在当时的做法并没有充分的利用好公司的资源，共同应对困难，可以设想，早一点把数据源方案拿上议程，利用好公司的坚实的技术支持，我们这次会少走很多弯路，也不会一再的在这个问题上被客户质疑我们的专业性，以及相应的速度。要知道这些印象都是通过平日的一点一滴积累的结果。
2. 对于很多问题，我们对于自己的想法缺乏证据去证明，我们过于乐观的估计了困难，其实没有被证明的就是错误的理论，在客户那里是将不通的。甚至是自己心里都没有底的事情，去到客户那里就很难讲得底气十足，很难拼回客户的信任感。
3. 还有另外一些问题，我们没有沉下心来深入去思考，去验证，我前面提出的若干点大家当作是抛砖引玉，大家可以补充，并且在今后的工作中都应该是同样的方式去面对和处理。
4. 测试环节我们把控不够，当然我这里不是说责任在测试的同事。我的意思是我们的质量意识还不够，其实每一次数据源方案的变更，都可以说是系统级的大范围受影响的，我们前后变更了3次，包括这次,我们从未提交过一份性能测试报告。没有这样东西，纵使我们花了很多力气去做方案，去实施，半夜三更的去做升级，做完了还写出一封长长的邮件跟客户说我们新的方案的种种好。实话跟大家讲，我写邮件的时候心里是没有底气的，因为那时我“认为”的好，客户可不一定认为好。我们之前被客户说的做的不好，也不是客户“认为”的，客户只能通过结果和事实来肯定或者否定我们的工作。

我们离完美的差距也许就是一点点，再多做一点点就可以让大家和客户都觉得很爽！我们的差距就在这里，这些东西是我们欠的，欠自己的，没法对自己交代的。还是那句话：出来混的，迟早要还的！何况是欠自己的，大家说呢？