自己開的坑幅聘，陸陸續(xù)續(xù)填坑中狼犯，自以為是地覺得基礎(chǔ)知識很扎實余寥，一個人接手了公司的一個小項目，結(jié)果遇到了多線程并發(fā)和阻塞的問題悯森，讓人欲哭無淚宋舷。特開此文，記錄開發(fā)中遇到的各種問題以及解決方法瓢姻，引以為戒祝蝠。
一、線程池
我所負責(zé)的項目是一個高并發(fā)的任務(wù)調(diào)度幻碱，所以就很想當(dāng)然地用到了線程池绎狭，線程池的基本原理也不用多說，但是不得不提的一點是線程池的拒絕策略褥傍，這個是經(jīng)常被大家所忽略的儡嘶，我當(dāng)初也是直接復(fù)制粘貼網(wǎng)上的代碼根本沒有細看，最后導(dǎo)致的一個問題就是任務(wù)沒法管理恍风，完全脫離了控制蹦狂。
我當(dāng)前的任務(wù)管理是用spring的定時器實現(xiàn)的，定時器的作用是每個一段時間就新建幾個任務(wù)提交給線程池進行處理朋贬，這樣可以保持任務(wù)的并發(fā)量維持在一定的量并且不會浪費cpu鸥咖，但是當(dāng)這類任務(wù)已經(jīng)完成，不再需要執(zhí)行時兄世，我關(guān)閉定時器，而任務(wù)還是在執(zhí)行之中啊研。其原因在于定時器的觸發(fā)間隔內(nèi)御滩，我所提交的任務(wù)線程池不一定能夠執(zhí)行完鸥拧，在舊有的任務(wù)沒有完成的情況下，又會有新的任務(wù)提交進來削解，這種情況得不到解決富弦，導(dǎo)致線程池被塞滿各種來不及執(zhí)行的任務(wù)。而當(dāng)定時器取消該任務(wù)并且不再提交時氛驮，線程池中的未執(zhí)行任務(wù)還在排隊等候腕柜，總有一天能夠被cpu翻到牌子得以運行，這也導(dǎo)致了任務(wù)數(shù)量超出預(yù)期效果矫废。
那么為了更好地控制任務(wù)盏缤，我們需要改變策略
1.在執(zhí)行任務(wù)的時候檢查任務(wù)數(shù)量是否足夠，然后再選擇執(zhí)行蓖扑。
我顯然不喜歡這種唉铜，強迫癥不允許這樣浪費
2.調(diào)整線程池大小，策略設(shè)置為拒絕所有律杠，就是隊列滿時再提交任務(wù)直接拒絕潭流。
rejectedExecutionHandler選擇AbortPolicy，其他策略可以自行百度
這樣的話同時也限制了其他任務(wù)柜去，我不能接受
3.待任務(wù)執(zhí)行完成再提交新的任務(wù)
這不得不提到spring自帶的定時任務(wù)了灰嫉，在spring4.x.x版本以上，實現(xiàn)了基于注解的定時器嗓奢，與quartz差不多讼撒，提供了三種定時器，cron,fixDelay和fixRate蔓罚。
cron是基于cron表達式的一種定時器椿肩，更靈活當(dāng)然也更復(fù)雜，fixDelay是每隔一段時間執(zhí)行一次任務(wù)豺谈，而fixRate顧名思義就是心跳郑象，與fixDelay差不多，但又有很大的不同茬末。
特別需要注意的是這些定時器的觸發(fā)策略厂榛。cron和fixDelay是在上一個定時任務(wù)完成之后再觸發(fā)定時器，也就是說如果前一個定時任務(wù)還沒有執(zhí)行完成丽惭，不會再創(chuàng)建新的定時任務(wù)击奶。只要當(dāng)前一個任務(wù)執(zhí)行完成之后再來啟動自己的定時功能，等到正確的時間進行觸發(fā)责掏。而fixRate則不同柜砾，它是不管上一個任務(wù)是否完成，都會在觸發(fā)器規(guī)定的時間內(nèi)創(chuàng)建一個定時任務(wù)换衬，可以說是相當(dāng)準(zhǔn)時痰驱。
基于以上证芭，我選擇了cron表達式。
