之前业务线上出现了es日表数据不一致的情况，我一开始一脸蒙蔽，后来请教同事也好，自己查阅资料也好，最后的问题其实是小到自己看不见的代码问题。最近是个空档期，记录一下血案。
业务场景描述：
业务项目中用户，股票，文章之间有着关联关系，线上数据越来越多时，采取的方案是数据首先落库，然后同步到es(elasticsearch)中，即是做缓存数据库，也方便了搜索业务需要。
后来随着用户和文章之间的关联关系数据量越来越大，决定对es按天分表，即每天会自动的产生一个天索引(这里的索引和mysql索引不一样)，es中索引的概念可以类比与mysql中数据库db的概念，类似于库，索引是具有某些相似特征的文档的集合。我们用的es版本较高，所以一个索引下只有一个type(type好比关系型数据库中的table)，type下有着大量的document。那出现的数据问题是什么呢？我们的业务逻辑代码是根据这个业务线中一条document中的publishTime字段来决定这条数据落到哪个索引中。比如这条数据中的publishTime为20191023，那它就会落到index_20191023这个索引中。但是现在居然在index_20191023这个索引中发现了其他天的数据，而且并没有规律可言，不同索引中有着很多不同日期的数据，造成了es数据的混乱。
主要从下面几个方面来排查：
1.es集群本身的问题，或许由于多节点，多分片造成的。
一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上。构成分布式搜索。分片的数量只能在索引创建前指定，并且索引创建后不能更改。
2.线上环境数据量太大，当代码中有线程不安全的地方，会造成数据错乱
3.关系型数据库同步到es的方案机制是否有问题
不管是哪个方面问题，核心就是根据字段publishTime找到相对应的es索引，然后存储这个过程除了问题，我一开始一度怀疑是es研发部门的问题，，，，我在document中多加了一个字段index，index就是publishTime的一种拼接形式，如果所有数据中index和es索引名一致，那就不是人家es部门的问题，如果不一致，说明落到es库时出了问题。但是我加了一条日志后，在线上看到的index和es索引是一样的，于是第一种原因就排除了。
之后几天反复的看预发环境和线上环境的数据，发现新测试的数据在预发环境上是保持一致的，没有错误。在线上就会出问题，看来就是数据量一上来，就会造成数据混乱，这显然就是代码中有危险的地方，有线程不安全的地方。
于是就回去仔细看代码，当然核心还是publishTime前前后后各种格式的转换，终于发现了simpledateFormat这个类，它是线程不全的，如果非要用它，那就不要让所有线程共享，应把它设置成局部变量。当然还有其他的解决办法，比如设置成threadLocal类型，或者利用同步锁。当然这里如果要用threadLocal的话，也是有点不稳妥的，如果线程数过多，threadlocal要是常驻内存会有风险，我当时也不确定threadlocal会不会释放回收，可能会造成内存泄漏的问题。
经过查阅资料，发现threadlocal内部果然会有无法释放的部分，如下图，实现是强引用，虚线是弱引用
每个thread中都存在一个map, map的类型是ThreadLocal.ThreadLocalMap. Map中的key为一个threadlocal实例. 这个Map的确使用了弱引用,不过弱引用只是针对key. 每个key都弱引用指向threadlocal. 当把threadlocal实例置为null以后,没有任何强引用指向threadlocal实例,所以threadlocal将会被gc回收. 但是,我们的value却不能回收,因为存在一条从current thread连接过来的强引用. 只有当前thread结束以后, current thread就不会存在栈中,强引用断开, Current Thread, Map, value将全部被GC回收.
所以最后修改bug就显而易见了，即保证线程初始化的时候单独调用simpledateFormat，各自享用空间，或者在jdk1.8之后有代替它的线程安全的类。
这次修复es线上数据优化问题其实很多时候都是代码中我们很难发现的一些不安全问题，但更重要的是排查问题的定位与分析。
