1.死锁

要提交快照的时候由于没有人取走applyCh通道里面的东西，导致死锁。

具体解释：

2D的测试代码中在日志达到一定大小时会调用snapshot，该函数需要申请rf.mu这个互斥锁。而在提交普通的日志条目时，错误地没有先释放锁，导致snapshot无法进行下去，相关的进程卡在rf.mu这个锁上，无法完成快照，更无法处理applyCh通道的下一个日志条目。这导致了向通道中提交日志条目也会因为applyCh已满而被阻塞。

2.快速定位错误

可以看到打印的日志中出现了“whe： u4"的信息，就可以推知：相关的错误发现在被u4标记的代码处，

在访问日志具体条目的代码处，传入相应的标记，这样当调用getEntry函数失败时，能快速定位目标。

3.由于截断日志增加的处理

发生u4报错，定位到相应代码。

在leader方，由于prevLogIndex处的日志条目被截取，小于rf.log.start(), 在运行getEntry函数时发生报错。

解决方法：

1.设置prevLogIndex = rf.log.start()

2.应发送给follower的日志条目被删除，直接发送快照给follower。

出错的点在于follower这边：leader方发送出去的时候prevLogIndex没有低于其自身的start，故没有发送快照，但是接收方收到日志条目之后，由于已经截断了日志，并不能匹配prevLogIndex。

显然接收方对这种情况也需要处理，并不能仅仅返回个error就完事了。

解决方案：

设置XLen为start（）+1， 即日志中的第一个条目，leader在收到回应的时候会执行nextIndex[i] = XLen, 这样就将nextIndex设置为follower方的日志第一个条目。

当prevLogIndex等于start时候，由于不匹配可能导致添加条目无法成功。

在截断日志的时候需要设置占位的条目的term为snapshot.term；无论是安装快照的时候，还是自己截断日志、生成快照的时候.

4关于应用（apply）时索引的思考

这是崩溃之前发送的消息，可以看出发送的最后一个索引号是223

这是重启之后，接收快照后而开始apply的快照，索引为229。

当start/restart后, 如果先发送的是日志条目，索引只能从1开始；但是如果是快照的话，索引可以从任意值开始，而其后的日志条目的索引值只需从该值递增即可。

一个有趣的发现：

TestSnapshotInstallUnCrash2D 每次只会使一个server崩溃，而TestSnapshotAllCrash2D 将会使得所有server同时崩溃；前者会使得commitIndex能够维持在正确值，而不回退，而后者会使得commitIndex从0开始。

5.发现不能通过从快照中恢复的测试

增加打印语句之后，发现restart之时都是没有带上快照的，这已经很说明问题了。

我并没有实现从稳定存储中读取快照的方法。

增添语句后，即可通过所有测试。

整个实验2大致需要花费364秒左右，还是很满意的。