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,后面存储方式修改为写入磁盘解决了问题