最近在做一个调度平台改造的项目，quartz在测试环境跑的是单机环境，生产上两台服务器做集群。
测试环境是ok的，生产上线后报错，一个类java.lang.classNotFoundException（注明：这个类被别人修改了名称，现在使用的新名字）
第一次：失败
从代码上排除了对旧的job类的引用（配置文件和类都排除了）
推测是服务器缓存了该类。
尝试：
清除缓存，重启服务器，仍然报上述错误。
第二次：失败
将生产上的配置拉到测试环境上，反复测试，重启服务器时会自动清除缓存。
推测是quartz的那个类为全局变量，在生产上会做同步。
尝试：
在测试环境上再次搭建一台调度服务器，从生产上将配置和执行全部拉到测试环境上，执行ok
反复调试，仍然没有发现同步的迹象。
没有重现生产上的异常，不敢上线了。
第三次：失败
那么这个旧的job类究竟从哪里调用的？找不到头绪！会不会保存到数据库吧？
当时觉得这个想法很搞笑，从设计的角度上来说，quartz应该不允许将别的类引入到自己的体系吧。
但也没路可走，就查看数据库，看看有没有保存在数据库中。你猜对了，它对原原本本的躺在数据库的表中：
CREATE TABLE QRTZ_JOB_DETAILS( JOB_NAME VARCHAR(200) NOT NULL, JOB_GROUP VARCHAR(200) NOT NULL, DESCRIPTION VARCHAR(250) NULL, JOB_CLASS_NAME VARCHAR(250) NOT NULL, IS_DURABLE VARCHAR(1) NOT NULL, IS_VOLATILE VARCHAR(1) NOT NULL, IS_STATEFUL VARCHAR(1) NOT NULL, REQUESTS_RECOVERY VARCHAR(1) NOT NULL, JOB_DATA BLOB NULL, PRIMARY KEY (JOB_NAME,JOB_GROUP)) TYPE=InnoDB;
好吧！ 查看该字段，发现确实是旧的类，被不是新的类。
那么为什么在测试环境中发现呢？
进入测试库，也没有发现旧的类，好吧。
第四次：成功
再次部署到生产上，还是报错：类找不到。
确认问题处在数据库中，我对quartz的表一张张的查找，仍然找不到这个记录，那就从写入库开始入手，查了quartz的代码，发现job_detail表中有个字段job_data，它的类型是blob，会不会存在这里呢？
确实，可以打开此blob查看，数据时放到这里了。
这个小心一些，再次检查是否有别的blob字段存放旧的job类，发现在triggers表中也有个字段job_data，至此问题发现了。可怎么解决呢？blob类型的数据不能直接通过update来执行，毕竟要考虑到编码的因素，拿就釜底抽薪，直接将类重构为以前的类。
从这次经历来看，旧项目果然是坑，我就直愣愣的掉进去了。
结论：
计算机是个理性的东西，故一切皆有可能，即便是最不可能的事情也要去一一确认。在查找问题时最好想清楚所有发生故障的可能，然后一一排除，直到找到最终的问题。
对web开发来说，解决此类问题的一般思路如下：
1，从全局的角度来看，应用程序，缓存，数据库是三大独立模块，这些部分都有可能发生异常，应该首先排查应用程序本身的异常（这个概率最大）；其次是缓存(同步)模块排查；最后是数据库模块排查。
2，全局确定好的前提下，细分上述的模块，将可能出现的问题一一列出。
3，动手，验证想法。对一个好的开发者来说，动手只是验证的手段，思路才是最重要的。