本篇文章將對(duì)項(xiàng)目搜索引擎（1）~（3）進(jìn)行性能優(yōu)化，包括測(cè)試，優(yōu)化思路，優(yōu)化前后對(duì)比

目錄

一：文件讀取

二：實(shí)現(xiàn)多線程制作索引

1：代碼分析

2：代碼測(cè)試

（1）第一次測(cè)試

（2）第二次測(cè)試

（3）測(cè)試總結(jié)

三：多線程實(shí)現(xiàn)代碼

1：線程池的選用

2：索引save執(zhí)行時(shí)機(jī)

（1）問(wèn)題分析

（2）解決思路

四：線程安全問(wèn)題

1：索引結(jié)構(gòu)中新增文檔線程安全分析

2：buildForward方法內(nèi)部代碼分析

3：builderInverted方法構(gòu)建倒排索引內(nèi)部代碼分析

4：加鎖對(duì)象的創(chuàng)建原理

5：優(yōu)化結(jié)果對(duì)比

6：思考是否線程數(shù)量越多越好呢？

7：守護(hù)線程

（1）現(xiàn)象

（2）關(guān)于守護(hù)線程

---

一：文件讀取

在進(jìn)行文檔正文解析的時(shí)候我們使用BufferReader來(lái)進(jìn)行文件讀取

可以理解為，BufferReader提供了一個(gè)緩沖區(qū)，每次文檔可以加載一部分內(nèi)容到內(nèi)存中的緩沖區(qū)（默認(rèn)大小是8192字節(jié)）里面，BufferReader就可以直接從內(nèi)存中讀了，減少了硬盤(pán)的IO操作，

        try (BufferedReader bufferedReader = new BufferedReader(new FileReader(f), 1024 * 1024)) {//緩沖區(qū)設(shè)置為1M,默認(rèn)的為8192字節(jié)太小
//            FileReader fileReader = new FileReader(f);//這里是從硬盤(pán)讀，我們改成提前讀好，之后從內(nèi)存中讀效率會(huì)更高

?我們的HTMl文檔比較大，就設(shè)置為1M大小了

二：實(shí)現(xiàn)多線程制作索引

1：代碼分析

思考：我們的的制作索引方法中核心的三步是，枚舉文件，解析文件（包含解析標(biāo)題，url，正文），保存文件。

2：代碼測(cè)試

    public static void main(String[] args) throws IOException, InterruptedException {Parser parser = new Parser();parser.run();
//        parser.runByThread();//制作索引}

（1）第一次測(cè)試

（2）第二次測(cè)試

（3）測(cè)試總結(jié)

細(xì)心的小伙伴能發(fā)現(xiàn)，同樣是run方法單線程制作索引，第一次和第二次測(cè)試，時(shí)間相差7s懸殊，這里其實(shí)跟電腦第一次啟動(dòng)有關(guān)，后續(xù)我會(huì)單獨(dú)拿出來(lái)講解優(yōu)化

這里我們先看用第二次測(cè)試結(jié)果：很明顯，遍歷解析文件耗費(fèi)的時(shí)間非常大，因?yàn)槲覀円獙?duì)每一個(gè)文件進(jìn)行：讀文件+分詞+解析內(nèi)容。這里我們可以進(jìn)行優(yōu)化

三：多線程實(shí)現(xiàn)代碼

public void runByThread() throws InterruptedException {long beg = System.currentTimeMillis();System.out.println("制作索引開(kāi)始！");//1：枚舉所有文件ArrayList<File> files = new ArrayList<>();enumFile(INPUT_PATH, files);long endEnumFile = System.currentTimeMillis();System.out.println("枚舉文件完畢，消耗時(shí)間為：" + (endEnumFile - beg) + "ms");//2：循環(huán)遍歷文件，多線程制作索引CountDownLatch latch = new CountDownLatch(files.size());//計(jì)數(shù)鎖存器ExecutorService executorService = Executors.newFixedThreadPool(4);//線程池for (File f : files) {executorService.submit(new Runnable() {@Overridepublic void run() {System.out.println("開(kāi)始解析" + f.getAbsolutePath());parseHTML(f);latch.countDown();}}); //解析每一個(gè)html文件}//await方法會(huì)阻塞，直到所有選手都調(diào)用contDown撞線之后，才能阻塞結(jié)束latch.await();//手動(dòng)干掉非守護(hù)線程executorService.shutdown();long endFor = System.currentTimeMillis();System.out.println("遍歷文件完畢！消耗時(shí)間為：" + (endFor - endEnumFile) + "ms");//3：把在內(nèi)存中構(gòu)造好的索引數(shù)據(jù)結(jié)構(gòu)，保存到指定的文件中index.save();long end = System.currentTimeMillis();System.out.println("多線程下索引制作完畢！消耗總時(shí)間為：" + (end - beg) + "ms");System.out.println("t1:" + t1 + ", t2:" + t2);}

1：線程池的選用

不用ThreadPoolExecutor，這里面我們要設(shè)置的參數(shù)太多啦，包括核心線程數(shù)，最大線程數(shù)，存活時(shí)間，時(shí)間單位，工作任務(wù)，線程工廠太多了

這里我們使用Executor中的靜態(tài)工廠方法newFixedThreadPool，只用傳參線程數(shù)量參數(shù)即可，返回類型為ExecutorService，它是一個(gè)接口，繼承于Executor接口。

可以通過(guò)ExecutorService類型變量的引用來(lái)調(diào)用線程池的各種方法，例如：任務(wù)提交，任務(wù)執(zhí)行，線程池關(guān)閉。

2：索引save執(zhí)行時(shí)機(jī)

（1）問(wèn)題分析

這里我們用了4個(gè)線程來(lái)并發(fā)解析我們html文件，那么問(wèn)題來(lái)了，是否會(huì)存在submit把文件都提交完畢了，但是線程池還沒(méi)解析完這些文檔，就進(jìn)行save索引保存方法了呢？顯然是有可能的。

那這里我們要確保所有的文檔都被解析完了之后，才進(jìn)行save，類似運(yùn)動(dòng)會(huì)跑步比賽，我們要等最后一名選手撞線了才能宣布比賽結(jié)束~~

（2）解決思路

這里我們使用了計(jì)數(shù)鎖存器CountDownLatch，先記錄下枚舉出來(lái)了所有文件個(gè)數(shù)，每解析完畢一個(gè)文件，就countDown一次，只有countDown到0之后才不會(huì)進(jìn)行阻塞，也就是latch.await才會(huì)放行！！

四：線程安全問(wèn)題

三個(gè)解析方法不涉及共同對(duì)象的修改，因此不存在線程安全問(wèn)題

1：索引結(jié)構(gòu)中新增文檔線程安全分析

不能在addDoc方法那里加鎖，這里加鎖的話，你并發(fā)執(zhí)行又變成串行了

2：buildForward方法內(nèi)部代碼分析

3：builderInverted方法構(gòu)建倒排索引內(nèi)部代碼分析

4：加鎖對(duì)象的創(chuàng)建原理

如果這兩個(gè)方法的加鎖對(duì)象為this（index），明顯是不很合理的，因?yàn)檎藕偷古攀莾蓚€(gè)不同的對(duì)象，所以我們可以設(shè)置不同的加鎖對(duì)象，這樣效率會(huì)更好，所以這里我們創(chuàng)建了兩個(gè)不同的加鎖對(duì)象

    //創(chuàng)建兩個(gè)鎖對(duì)象private Object locker1 = new Object();private Object locker2 = new Object();

就好比

5：優(yōu)化結(jié)果對(duì)比

時(shí)間的提升還是非常明顯了，提升了近1倍的速度

t1是用來(lái)衡量解析全部html文件中，解析全部Url所耗費(fèi)的時(shí)間

t2則是解析全部content所耗費(fèi)的時(shí)間，這里之所以不采用打印的方式，是因?yàn)榇蛴”旧砭褪且粋€(gè)耗時(shí)的操作，所以用累加的方式精確到納秒

6：思考是否線程數(shù)量越多越好呢？

不是的，線程數(shù)量越多，其實(shí)彼此間的鎖競(jìng)爭(zhēng)越激烈，優(yōu)化的空間很小了，4個(gè)線程數(shù)量再往上提提升不大了

7：守護(hù)線程

（1）現(xiàn)象

我們線程執(zhí)行完畢了，但是進(jìn)程還沒(méi)有退出。

（2）關(guān)于守護(hù)線程

如果一個(gè)線程是守護(hù)線程（后臺(tái)線程），那么它的運(yùn)行狀態(tài)是不會(huì)影響進(jìn)程結(jié)束的

相反，一個(gè)線程是非守護(hù)線程，它的運(yùn)行狀態(tài)是會(huì)影響到進(jìn)程結(jié)束的。

通俗一點(diǎn)舉例理解：

我們用這行代碼創(chuàng)建出來(lái)的是非守護(hù)線程，當(dāng)我們這些線程執(zhí)行的任務(wù)結(jié)束后，這些線程還是處于整裝待發(fā)的狀態(tài)——等你提交任務(wù)，所以線程的這種狀態(tài)就會(huì)影響到進(jìn)程的結(jié)束！

        //手動(dòng)干掉非守護(hù)線程executorService.shutdown();

這里我們手動(dòng)干掉創(chuàng)建出來(lái)的這些線程，女少！~