接到一個(gè)項(xiàng)目要求，要求很簡(jiǎn)單---統(tǒng)計(jì)出文件加下文件中指定的某些指令的出現(xiàn)次數(shù)。

    根據(jù)要求將問題分解為以下幾塊：

    1、要統(tǒng)計(jì)的指令，這個(gè)用腳趾頭想都要放到配置文件中，根據(jù)操作的文件語(yǔ)法格式，將不同模塊類型下的指令以JSON數(shù)組的形式進(jìn)行配置存放，格式如下

           {"C_OPERS": ["MOVE","CLEAR","WRITE"], "D_DEFINE": ["DIM","S"]} 

    2、獲取指定目錄下所有文件，以文件數(shù)組返回， 采用遞歸方式獲取。

private void scanAllDirs(String dirPath) {
        File file = new File(dirPath);

        if (file.isDirectory()) {
            File[] files = file.listFiles();
            for (File f: files) {
                scanAllDirs(f.getAbsolutePath());
            }
        } else {
            try {
                queue.put(file.getAbsolutePath());
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

    3、根據(jù)步驟2中得到的文件數(shù)組循環(huán)調(diào)用另外的解析模塊代碼進(jìn)行解析，可以獲取一個(gè)文件中指令的出現(xiàn)次數(shù)。

    4、累計(jì)統(tǒng)計(jì)。

   單個(gè)文調(diào)試無問題，由于文件數(shù)量比較多自然的想到了使用多線程來提升效率，采用典型的生產(chǎn)者消費(fèi)者模式。

   將生產(chǎn)者和消費(fèi)者的比例設(shè)置為1:3，BlockingQueue初始值設(shè)置為1000，然后再套一層生產(chǎn)者消費(fèi)者模式，總體就變成了

   先生成文件，使用消費(fèi)者消費(fèi)文件后得到單個(gè)文件中指令出現(xiàn)的次數(shù)，用單個(gè)文件中出現(xiàn)的文件次數(shù)再進(jìn)行一次生成，最后再調(diào)用新消費(fèi)者，進(jìn)行消費(fèi)統(tǒng)計(jì)。

   理想很美好，現(xiàn)實(shí)很殘酷，運(yùn)行程序發(fā)現(xiàn)還是很慢，2300多個(gè)文件運(yùn)行了3個(gè)多小時(shí)居然還沒統(tǒng)計(jì)完畢。

   果斷終止程序，分析到底是哪里導(dǎo)致的系統(tǒng)運(yùn)行的這么慢。

  第一、看文件解析所消耗的時(shí)間，單個(gè)文件解析的時(shí)間基本在之分之一秒內(nèi)，然后將文件解析數(shù)量增加至10個(gè)，發(fā)現(xiàn)解析時(shí)間沒有明顯增加，看來解析文件不是導(dǎo)致程序慢的原因，暫時(shí)先放下。

  第二、接下來就是生產(chǎn)者消費(fèi)者模式了，這個(gè)是經(jīng)歷過n多java大師和前輩驗(yàn)證過的模式不會(huì)有什么問題

  第三、BlockingQueue的初始值，初始值是根據(jù)感覺來設(shè)置的，1000是不是有點(diǎn)小，那就改2000試試，調(diào)試后濤聲依舊。看來改大不行，暫時(shí)先放下

  第四、把生成者模式改成1:1的最簡(jiǎn)單的方式把嵌套的二級(jí)生產(chǎn)者消費(fèi)者模式去掉進(jìn)行調(diào)試，程序運(yùn)行還是很慢。

  到此有點(diǎn)卡殼了。程序已經(jīng)很簡(jiǎn)單了，那唯一可能的地方就是BlockingQueue的初始值了，因?yàn)橐郧案杏X設(shè)置的越大越好。接下來反其道而行至，將BlockingQueue的初始值設(shè)置為100。

  運(yùn)行程序，黃天不付有心人，我對(duì)了，這次解析完所有文件只花費(fèi)了26分鐘，和之前的相比簡(jiǎn)直是天壤之別。然后再加入累計(jì)所有文件中指令的for循環(huán)。因?yàn)橹噶畹膫€(gè)數(shù)是以key：value形式存儲(chǔ)，

  開始使用的是HashMap存儲(chǔ)，跑一下時(shí)間在56分鐘左右，這下?lián)Q就比較清晰了，是HashMap導(dǎo)致的性能瓶頸，KO，換，使用并發(fā)包ConcurrentHashMap，再次運(yùn)行時(shí)間重回30分鐘內(nèi)。

  小結(jié)：?jiǎn)栴}的關(guān)鍵點(diǎn)在于初始化時(shí)裝在的數(shù)據(jù)太多，使用生產(chǎn)者消費(fèi)者模式和BlockingQueue解決了一次性裝在數(shù)據(jù)太多的問題，然后再使用并發(fā)包提升性能。

  隱含問題：當(dāng)指令數(shù)量增加時(shí)程序還會(huì)變慢這個(gè)是當(dāng)前的設(shè)計(jì)和要求所來了的必然問題，后續(xù)如果還要提升性能那就要重新設(shè)計(jì)。