本篇文章将对项目搜索引擎（1）~（3）进行性能优化，包括测试，优化思路，优化前后对比

目录

一：文件读取

二：实现多线程制作索引

1：代码分析

2：代码测试

（1）第一次测试

（2）第二次测试

（3）测试总结

三：多线程实现代码

1：线程池的选用

2：索引save执行时机

（1）问题分析

（2）解决思路

四：线程安全问题

1：索引结构中新增文档线程安全分析

2：buildForward方法内部代码分析

3：builderInverted方法构建倒排索引内部代码分析

4：加锁对象的创建原理

5：优化结果对比

6：思考是否线程数量越多越好呢？

7：守护线程

（1）现象

（2）关于守护线程

---

一：文件读取

在进行文档正文解析的时候我们使用BufferReader来进行文件读取

可以理解为，BufferReader提供了一个缓冲区，每次文档可以加载一部分内容到内存中的缓冲区（默认大小是8192字节）里面，BufferReader就可以直接从内存中读了，减少了硬盘的IO操作，

        try (BufferedReader bufferedReader = new BufferedReader(new FileReader(f), 1024 * 1024)) {//缓冲区设置为1M,默认的为8192字节太小
//            FileReader fileReader = new FileReader(f);//这里是从硬盘读，我们改成提前读好，之后从内存中读效率会更高

 我们的HTMl文档比较大，就设置为1M大小了

二：实现多线程制作索引

1：代码分析

思考：我们的的制作索引方法中核心的三步是，枚举文件，解析文件（包含解析标题，url，正文），保存文件。

2：代码测试

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

（1）第一次测试

（2）第二次测试

（3）测试总结

细心的小伙伴能发现，同样是run方法单线程制作索引，第一次和第二次测试，时间相差7s悬殊，这里其实跟电脑第一次启动有关，后续我会单独拿出来讲解优化

这里我们先看用第二次测试结果：很明显，遍历解析文件耗费的时间非常大，因为我们要对每一个文件进行：读文件+分词+解析内容。这里我们可以进行优化

三：多线程实现代码

public void runByThread() throws InterruptedException {
        long beg = System.currentTimeMillis();
        System.out.println("制作索引开始！");

        //1：枚举所有文件
        ArrayList<File> files = new ArrayList<>();
        enumFile(INPUT_PATH, files);
        long endEnumFile = System.currentTimeMillis();
        System.out.println("枚举文件完毕，消耗时间为：" + (endEnumFile - beg) + "ms");

        //2：循环遍历文件，多线程制作索引
        CountDownLatch latch = new CountDownLatch(files.size());//计数锁存器
        ExecutorService executorService = Executors.newFixedThreadPool(4);//线程池
        for (File f : files) {
            executorService.submit(new Runnable() {
                @Override
                public void run() {
                    System.out.println("开始解析" + f.getAbsolutePath());
                    parseHTML(f);
                    latch.countDown();
                }
            }); //解析每一个html文件
        }
        //await方法会阻塞，直到所有选手都调用contDown撞线之后，才能阻塞结束
        latch.await();
        //手动干掉非守护线程
        executorService.shutdown();
        long endFor = System.currentTimeMillis();
        System.out.println("遍历文件完毕！消耗时间为：" + (endFor - endEnumFile) + "ms");

        //3：把在内存中构造好的索引数据结构，保存到指定的文件中
        index.save();
        long end = System.currentTimeMillis();
        System.out.println("多线程下索引制作完毕！消耗总时间为：" + (end - beg) + "ms");
        System.out.println("t1:" + t1 + ", t2:" + t2);
    }

1：线程池的选用

不用ThreadPoolExecutor，这里面我们要设置的参数太多啦，包括核心线程数，最大线程数，存活时间，时间单位，工作任务，线程工厂太多了

这里我们使用Executor中的静态工厂方法newFixedThreadPool，只用传参线程数量参数即可，返回类型为ExecutorService，它是一个接口，继承于Executor接口。

可以通过ExecutorService类型变量的引用来调用线程池的各种方法，例如：任务提交，任务执行，线程池关闭。

2：索引save执行时机

（1）问题分析

这里我们用了4个线程来并发解析我们html文件，那么问题来了，是否会存在submit把文件都提交完毕了，但是线程池还没解析完这些文档，就进行save索引保存方法了呢？显然是有可能的。

那这里我们要确保所有的文档都被解析完了之后，才进行save，类似运动会跑步比赛，我们要等最后一名选手撞线了才能宣布比赛结束~~

（2）解决思路

这里我们使用了计数锁存器CountDownLatch，先记录下枚举出来了所有文件个数，每解析完毕一个文件，就countDown一次，只有countDown到0之后才不会进行阻塞，也就是latch.await才会放行！！

四：线程安全问题

三个解析方法不涉及共同对象的修改，因此不存在线程安全问题

1：索引结构中新增文档线程安全分析

不能在addDoc方法那里加锁，这里加锁的话，你并发执行又变成串行了

2：buildForward方法内部代码分析

3：builderInverted方法构建倒排索引内部代码分析

4：加锁对象的创建原理

如果这两个方法的加锁对象为this（index），明显是不很合理的，因为正排和倒排是两个不同的对象，所以我们可以设置不同的加锁对象，这样效率会更好，所以这里我们创建了两个不同的加锁对象

    //创建两个锁对象
    private Object locker1 = new Object();
    private Object locker2 = new Object();

就好比

5：优化结果对比

时间的提升还是非常明显了，提升了近1倍的速度

t1是用来衡量解析全部html文件中，解析全部Url所耗费的时间

t2则是解析全部content所耗费的时间，这里之所以不采用打印的方式，是因为打印本身就是一个耗时的操作，所以用累加的方式精确到纳秒

6：思考是否线程数量越多越好呢？

不是的，线程数量越多，其实彼此间的锁竞争越激烈，优化的空间很小了，4个线程数量再往上提提升不大了

7：守护线程

（1）现象

我们线程执行完毕了，但是进程还没有退出。

（2）关于守护线程

如果一个线程是守护线程（后台线程），那么它的运行状态是不会影响进程结束的

相反，一个线程是非守护线程，它的运行状态是会影响到进程结束的。

通俗一点举例理解：

我们用这行代码创建出来的是非守护线程，当我们这些线程执行的任务结束后，这些线程还是处于整装待发的状态——等你提交任务，所以线程的这种状态就会影响到进程的结束！

        //手动干掉非守护线程
        executorService.shutdown();

这里我们手动干掉创建出来的这些线程，女少！~