本地环境可以，生产环境不行（持续补充）

“我本地是可以的啊，为什么生产上就不行了？？？”

上面那句话相信大家都有说过，现在似乎已经被戏称为“程序员最大的谎言”，呵呵……我就来以我个人的遭遇来总结下教训。

 

场景一：单独把自己在本地编译无误，测试无误的类编译成class文件放到生产环境。

大部分情况下我们都是这么做的，本来在本地跑得好好的代码，上了生产死活跑不起来，而且还不报错……

       我碰到这种情况的时候，是因为我在本地的该class文件对应的java文件里，注释了暂时还不需要上线的方法A，而方法A又调用了方法B，方法B里的代码涉及到了还未提交上线的其他类或方法。虽然在我本地编译无误，也生成了一个class文件，新功能的调用者方法A我也注释掉了，但是直接把这个class文件放到生产环境其实是编译错误的。因为生产环境的class文件还没有你的方法B里未提交的类或方法……

      办法是提交你的代码，由负责升级打包的组长更新，他的对应的Java文件肯定是编译不通过的，因为方法B编译未通过。因为你还暂时不能提交B，所以他删掉你新加的（还不需要上线）功能方法A，以及它的依赖方法B，再重新打包成class文件即可。

    以上，就要求到我们升级打包的规范性操作。。这种潜在的错误是很容易犯的。

 

场景二：确保本地环境和生产环境的jdk版本环境是一致的，因为不同jdk版本，对一些语法的支持略有差异。

 

场景三：本地一般是单机环境，生产环境大多数情况下都是负载均衡的，当一些缓存数据在启动的时候需要保存在内存中的时候，重启该台机器会清空内存中的缓存数据。而如果需要读到该缓存数据，当还没初始化完成时，往往可能造成NullPointerException（因为初始化到缓存中需要一定时间。）。若希望不受重启影响，建议把缓存数据存放在nosql数据库中，如redis, mongodb, cassandra等，这样多台机器就共用同一个缓存中间件，任意机器的重启并不会造成缓存数据被清空，而读取缓存数据的·时候就改由从缓存中间件中读取而非内存中读取~~  项目启动的时候初始化缓存最好采用异步的方式，而不是用线程阻塞的方式。。

 

场景四：针对同一批数据重跑，指望跑出的数据覆盖原数据，结果发现重复。——排查表的主键是否是自动生成策略生成。

 

=====================持续补充=========================