本篇文章将对项目搜索引擎（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();这里我们手动干掉创建出来的这些线程，女少！~
