工作问题总结

1.场景描述：在本地和测试环境能正常打印日志，在预发布环境不能打印日志
问题解决：org.slf4j.LoggerFactory包读的是log4j2.xml文件，org.apache.log4j.Logger读的是log4j.Properties文件，而且在不配置log4j.Properties文件的情况下在本地是能打印出日志的，在预发布不能打印的原因未知，但改成org.slf4j.LoggerFactory之后在预发布能正常打印日志，此时在本地又不能打印日志了，经过查找，在eclipse中不打印日志到控制台原因：

在log4j2.xml中没有配置上图。
问题总结：在工程中打印统一使用LoggerFactory。
2.场景描述：服务器的线程会随着时间的推移被占用，从而导致服务器假死
问题解决：阿里云上报日志的配置没有加，导致线程被占用，从而导致服务器假死
看了一下源码，没发现会造成死锁的地方，但有很多地方使用了读写锁，猜测是代码执行时间很长，导致线程占用时间长。
问题总结：目前没有有效方法，只有细心了，再有的话就是拿配置参数时对参数进行判空操作
3.场景描述：服务器启动后随着时间的推移，会报redis链接数不够
问题解决：开始怀疑的是新引入的ridisson的jar包导致的，因为这似乎这次上线的最大的变量，然后把jar包删除后仍没解决，后怀疑是某个key太大导致查询的时间过长或代码里有逻辑不对的地方导致不停在请求redis。经过查找并不存在这些问题（除了在用户动作上报时有一些效率问题），后来怀疑是某些redis命令执行后没有释放链接，导致连接数不断的被占用而不释放。启明通过查看spring提供的模板类RedisTemplate的源码，发现zscan方法是不会释放连接数的：

而其他方法使用的execute方法都会在finally里释放链接数：

问题总结：只能说是经验吧，之前没碰到zscan方法也就办法了
4.场景描述：一个redis的key在上线时数据量从几百一下增加到十几万，这期间还发生了一次阿里云自动回收key的机制，导致几百万个key被回收
问题解决：首先此key是一个永久key，在正常情况下不会没有value，在有value的情况下就不会去mysql查数据导致数据量一下增大，所以首先怀疑是key被清除了，而且此时阿里云正巧自动回收key导致几百万个key被回收，就感觉此key也是被阿里云回收了。但我们设置的回收策略是lru算法，原则上是不会回收永久key的，所以花了一部分时间在跟阿里那边沟通。另一方面我们也在修复被删除的缓存和扩容了redis，在缓存修复好了之后再次上线还是出现了问题，此时后台报拿不到连接数的错，此key又一次增大，但redis日志显示没有回收key。说明此次是key没有失效的，但为什么访问mysql呢，是有一段时间正好为空然后请求的mysql，经过查找数据排除此种可能，后来通过阿里的帮助和查看工程底层代码，发现是底层代码把获取连接数的Exception吃掉了，导致程序误认为是缓存没有了，然后就去查mysql了，到此主要问题查到了，那么是说明原因导致连接数不够呢，从redis日志没看到执行特别慢的key啊？后来阿里那边告诉redis日志显示的时间不是执行时间而是聚合时间，通过他们后台的查询发现确实有一个执行几秒的key，至此问题就明了了：大量慢查询导致线上redis拿不到链接数，而此时错误被吃导致误认为缓存没有而查mysql再加上线上的并发，导致了mysql和redis闪崩。
问题总结：最根本原因应该是建工程的人把exception吃掉了，不然不会导致如此严重的后果，这也说明不能随便乱try-catch。