【从0做项目】Java搜索引擎（4）——性能优化~烧脑~~~

本篇文章将对项目搜索引擎（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() {@Overridepublic 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();

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