多线程学习笔记

1、线程池的四种拒绝策略：当线程池的线程数量达到最大，并且队列满了之后，对后续任务的策略
A、（默认）AbortPolicy：拒绝后面的任务，并抛出RejectedExecutionException异常

B、CallerRunsPolicy：将任务交给当前调用线程执行，如主线程

C、DiscardPolicy：抛弃后续任务，并且不抛异常
C、DiscardOldestPolicy：取消队列最前面的任务，将当前任务放进去

2、线程池线程的创建条件:
A、核心线程：当前线程池没有空闲线程，并且线程数量小于核心线程
B、其他线程：核心线程已满，并且队列也满了

3、LockSupport.park()和LockSupport.unpark();
LockSupport.park()阻塞线程，LockSupport.unpark()唤醒线程，LockSupport.park()不会释放线程
https://www.cnblogs.com/tong-yuan/p/11768904.html

4、CopyOnWriteArrayList是arrayList的线程安全版，CopyOnWriteArrayList的每次修改都会创建一个新的数组，然后将旧的数组复制进去，然后修改新的数组，这样保证了只阻塞写操作，而不会阻塞读操作，实现了读写分离。

5、导入文件时报The supplied file was empty (zero bytes long)
经排查发现，是解析文件的sheet名称的时候报的错，看报错原因解释是对这个流进行了多次操作，导致第二次解析的时候认为这个文件是空文件
后经过排查代码，发现在解析文件之前将文件上传到了文件服务器，打断点调试，发现上传文件服务器之后流出现了变化，后面不上传文件服务器
之后确实可以解析，但是想到其他服务也用到了这个导入框架，但是其他的服务没有这个问题，而且业务上要求原始文件必须上传文件服务器，所以
绕过上传是行不通的，只能继续排查。
后来通过对比其他正常的服务，发现导入文件的FileUpload类不同，正常的服务是DiskFileUpload，而报错的服务是MixedFileUpload，发现是存储
方式不同，导致两个类不同，而这次导入的文件小于16K，所以最后用的是MemoryFileUpload，后面存储方式修改为写入磁盘解决了问题