自己開的坑，陸陸續(xù)續(xù)填坑中，自以為是地覺得基礎(chǔ)知識很扎實，一個人接手了公司的一個小項目，結(jié)果遇到了多線程并發(fā)和阻塞的問題，讓人欲哭無淚。特開此文，記錄開發(fā)中遇到的各種問題以及解決方法，引以為戒。
一、線程池
我所負責的項目是一個高并發(fā)的任務調(diào)度，所以就很想當然地用到了線程池，線程池的基本原理也不用多說，但是不得不提的一點是線程池的拒絕策略，這個是經(jīng)常被大家所忽略的，我當初也是直接復制粘貼網(wǎng)上的代碼根本沒有細看，最后導致的一個問題就是任務沒法管理，完全脫離了控制。
我當前的任務管理是用spring的定時器實現(xiàn)的，定時器的作用是每個一段時間就新建幾個任務提交給線程池進行處理，這樣可以保持任務的并發(fā)量維持在一定的量并且不會浪費cpu，但是當這類任務已經(jīng)完成，不再需要執(zhí)行時，我關(guān)閉定時器，而任務還是在執(zhí)行之中。其原因在于定時器的觸發(fā)間隔內(nèi)，我所提交的任務線程池不一定能夠執(zhí)行完，在舊有的任務沒有完成的情況下，又會有新的任務提交進來，這種情況得不到解決，導致線程池被塞滿各種來不及執(zhí)行的任務。而當定時器取消該任務并且不再提交時，線程池中的未執(zhí)行任務還在排隊等候，總有一天能夠被cpu翻到牌子得以運行，這也導致了任務數(shù)量超出預期效果。
那么為了更好地控制任務，我們需要改變策略
1.在執(zhí)行任務的時候檢查任務數(shù)量是否足夠，然后再選擇執(zhí)行。
我顯然不喜歡這種，強迫癥不允許這樣浪費
2.調(diào)整線程池大小，策略設(shè)置為拒絕所有，就是隊列滿時再提交任務直接拒絕。
rejectedExecutionHandler選擇AbortPolicy，其他策略可以自行百度
這樣的話同時也限制了其他任務，我不能接受
3.待任務執(zhí)行完成再提交新的任務
這不得不提到spring自帶的定時任務了，在spring4.x.x版本以上，實現(xiàn)了基于注解的定時器，與quartz差不多，提供了三種定時器，cron,fixDelay和fixRate。
cron是基于cron表達式的一種定時器，更靈活當然也更復雜，fixDelay是每隔一段時間執(zhí)行一次任務，而fixRate顧名思義就是心跳，與fixDelay差不多，但又有很大的不同。
特別需要注意的是這些定時器的觸發(fā)策略。cron和fixDelay是在上一個定時任務完成之后再觸發(fā)定時器，也就是說如果前一個定時任務還沒有執(zhí)行完成，不會再創(chuàng)建新的定時任務。只要當前一個任務執(zhí)行完成之后再來啟動自己的定時功能，等到正確的時間進行觸發(fā)。而fixRate則不同，它是不管上一個任務是否完成，都會在觸發(fā)器規(guī)定的時間內(nèi)創(chuàng)建一個定時任務，可以說是相當準時。
基于以上，我選擇了cron表達式。
