程序员要注意代码质量

这两天一直被一个问题困扰，客服那边反馈过来的消息是“奴隶时代”产品用户反应经常卡,先安排程序员上服务器查看什么情况，没看出来什么，大抵就是数据库 卡一类的，然后抛EOF的exception，然后我就让他调高参数一类的solution。期待有些作用，哪知道这两天依然如此，并且造成个人家园的卡 的问题，因为个人家园里有从奴隶时代的http接口中请求数据的部分，而奴隶时代又同时需要调用个人家园中的短信协议部分，这个问题周六周日一直存在，并 且在用户收入上也表现出来了，大概每天的收入少了好几千块，于是周六做完午饭就没出去，一直盯着服务器，顺便翻翻他们的code。

一开始的决定是用spring的dbcp来取代现有的tomcat连接池机制，因为涉及到注入的问题，并且需要修改引用的8个class对这个业务 util类的调用，于是决定采用手工获取applicationContext的方法，由于这个业务util类是coder从我以前的项目中copy过来 用的，而那个项目已经是99年的code了，获取连接的方法采用的是synchronized,结果造成spring的 applicationContext的不断加载，于是放弃。就在这时刻，我发现这个方法的调用在这个util类的构造函数中，再去find usage，发现调用的地方在业务一开始的时候就实例化了这个对象，而等业务代码处理完成之后才来调用这个业务类，结果造成connection的无效关 闭。于是去掉构造函数，将此方法挪到实际方法中，问题解决。

在问题没解决的时候出现的症状有如下几种： 1.apache连接数被无限制加大到最大值，为此我把apache的maxclient调至1400，tomcat的最大实例也调到800，依然没有作 用，在application刚启动的时候看起来还不错，运行一段时间以后就会出现mysql空闲状态，没有数据请求，processlist中数目降至 2条，tomcat和apache都已无法使用。

2.apache连接数到达峰值，直接请求tomcat可以访问，请求apache无效，重启apache，应用恢复正常

其中第二种情况是早期，第一种情况是晚期。

也就是说我们在遇到问题的时候顺藤摸瓜，还得眼明手快。

总之问题解决了，明天去要再次强调程序员要注意自己的代码质量。

老婆喊我吃饭了。再见