项目场景：
在项目批量导入模板数据的时候遇到的一些关于多线程的问题
问题描述
众所周知在批量导入excel的数据时一般使用阿里巴巴的EasyExcel，内置多线程的处理，但是有一个很大的弊端就是，baseExcel的每一个属性都是固定的，才可以使用，现在就是导入的模板根据数据库的字段实时变化，对于easyExcel并不适用（也可能是我对easyExcel使用并不熟练），在网上未找到解决办法之后，只能自己按照easyExcel的逻辑实现功能，下面是我在过程中遇到的一系列问题，主要是关于多线程和数据库连接的问题：
##正常使用esayExcel模板：
@ExcelPorperty
private String name;
@ExcelPorperty
private String code;
- 现在导入模板随数据库的数据而变化，固不能使用easyExcel导入，下面是我的解决办法：通过ExcelUtil来parse每一行数据，和数据库读取出来的column的map做对照，然后手动处理每一行的数据（这里还是比较简单的）：
List<Map<String,Object>> mapList = ImportExcelUtil.parseExcel(file.getInputStream(),map);
map是数据库查询出来的column，file是导入的文件，工具类我放在附件里面
- 现在因为一个模板导入有万条数据，如果一条一条处理很浪费时间，这里使用多线程来分批次处理，多线程真的很多坑，先分批次切片：
- 下面是主要的分析环节，主要是对数据进行去重，数据库查询字段是否匹配，数据库是否重复，业务逻辑不详细讲解，这里使用了CountDownLatch（CountDownLatch详解）同步锁，CountDownLatch允许一个或者多个线程去等待其他线程完成操作。多线程一般和锁配合使用，这里也是导致我后面遇到了一个问题：
CountDownLatch latch = new CountDownLatch(mapList.size());
主要遇到的问题：
1.
多线程共享静态变量的问题
学习过多线程的应该了解静态变量，这边是原本打算写一个静态变量的List<>收集每个线程发生的报错，后面统一返回，首先在回答共享变量之前,我们应该搞清的是什么是线程安全?
对于线程的安全,通过博客我们可能会得到很多的答案,但在这里我结合一点自己的想法和感受谈谈线程安全
我想本质的问题就是:启动线程的方法是start方法,但是真正运行线程的方法是run方法,所以线程安全不安全取决于run方法中的代码的执行的结果是否一致,如果start启动的的是多个线程,而run中运行的是多个线程,如果当单个线程运行的结果和多个线程运行的结果不一样时,那么线程必定是不安全的,反之,如果这多个线程运行的结果和单个线程运行的结果是一致的,那么必然是线程安全的,也就是说,run’中的代码运行的结果是一致的,所以这个问题就解决了;下面我们回答共享变量的问题;
假如有三个线程:线程一,线程二,线程三,三个线程同时启动区访问一个共享变量x,从java虚拟机的角度来说,共享变量存在主内存中.但是变量的修改不能再主内存中修改,因此每一个变量对应的每一个线程都有一个工作内存区域,而这个区域就是每一个变量的修改的区域,也就是说:变量的修改是在工作内存中修改的,而非是在主内存中修改的,为了保证共享变量的可见性,加一个互斥锁,这个目的是保证某一段时间只能由一个线程修改变量,但是下一个线程读取变量的值,一定是在主内存中读取的,其实说白了就是一下三点:
1.主内存-------->修改后的变量,用于读取
2.工作内存------>共享变量真正修改的地方
3.互斥锁---------->保证共享变量的安全性;
volidate:
强迫修改后的值,保存在主内存中;
原子性:
sybchonized:具有可见性和原子性,volidate不具有原子性;
但是静态变量在所有线程共享，假设别的租户同时使用了这个方法导入模板，很可能会导致数据发生互通，所以这个方案无法实现，这个bug也是在上线之后才发现，后面更改成另一种方案：
使用局部变量，每个线程返回到主线程当中，然后统一收集，但是代码量增多
2.
多线程上下文不共享的问题
公司使用上下文来获取当前用户的公司和租户信息，但是上下文只在主线程中有效，在线程池（线程池详解）中没有上下文，解决办法比较简单，手动创造上下文，把值传入其他线程之中
3.
线程池配置问题
关于项目中的线程配置，多数看项目具体的数据量和cpu数量，这边项目大概数据1w条，每个线程500条，大概需要20个线程，线程池的优化对效率的作用至关重要，在项目中我因为开始线程池配置的maxPoolSize设置的Integer.MAX,导致数据内存溢出，项目oom，所以线程池的配置至关重要。ThreadPoolExecutor部分源码
构造方法:
public ThreadPoolExecutor(int corePoolSize, //核心线程数量
int maximumPoolSize,// 最大线程数
long keepAliveTime, // 最大空闲时间
TimeUnit unit, // 时间单位
BlockingQueue<Runnable> workQueue, // 任务队列
ThreadFactory threadFactory, // 线程工厂
RejectedExecutionHandler handler // 饱和处理机制
)
4.
CountDownLatch 未释放导致数据库连接过多
CountDownLatch 是一个适用于当前项目的锁，这边设置的size等一线程总数，在每个线程处理完毕之后执行countDownLatch.countDown释放，主线程中使用countDownLatch.await()阻塞，当所有线程执行完毕之后countDownLatch才释放，主线程运行，可以有效的处理数据，但是这也导致了一个问题：
其他线程出现了问题：例如数据不匹配，数据库查询报错，非抛出式异常导致线程中断，并未释放countDownLatch，主线程一直countDownLatch.await()导致线程一直阻塞，占用数据库连接，在多次调试之后，占用的数据路连接已经超过数据库的最大连接数，最后数据库连接占用过多导致出错
这个bug十分隐晦所以在开始的时候没有发现，但是仍然值得重视，解决办法就是，在线程的try-catch-finally中加入countDownLatch.countDown，无论线程是否报错都释放锁，主线程不阻塞
总结
多线程在使用过程中涉及锁，静态变量，上下文，线程间的同步与互斥，线程池配置，需要一定的积累才能使用的好，在很多官方模块中也使用了线程，以前总是使用现成的轮子，现在造轮子才知道轮子多难造，还是尽量使用官方的代码块，所以easyExcel什么时候有根据数据库实时变动column的功能，我就不用操这么多心了，只能说代码的迭代需要一代接一代
