出错总有原因 之 匆忙引入多线程引发的Crash

         一年之前，考虑到性能问题，需要引入多线程的工作机制来将数据备份到云存储上，但是时间要求得非常急迫，而原有代码完全是处于年久失修的状况，根本来不及重新设计，于是只有在原来的基础上开辟多个线程，每个线程上传一个文件。每个线程都有自己的文件对象，看上去好像各个线程间没有共享什么对象，每个线程所用到的日志类也是线程安全的，看上去问题不大。
        但实际测试中还是发生了Crash，可奇怪的是，只有在客户机器那里才会出现。
        拿到Dump后才发现，虽然每个线程都使用了自己的文件对象，但是各个文件对象共用了同一份Cache，这个Cache用来记录访问过的文件Id以提升性能，避免频繁的去服务器查询Id，这个Cache组织成为一个Map,是需要加锁的，否则多个线程同时访问一个Map肯定是会出问题的。文件类是很久以前写好的，并没有考虑过线程安全的问题，所以自然就会出现Crash的问题啦！
        搞笑的是，测试人员不认为存在问题，因为他们无论如何也重现不了这个Bug。代码中明显存在的问题，按道理应该很容易重现才对。我加了一些OutputDebugString语句在DbgView中输出才发现，由于云服务器在国外，国内网速很慢，所以各个线程每次从服务器取到文件Id都刚好存在一个时间差，于是导致将这些信息存入Cache的时候也存在一个时间差，居然在绝大多数情况下不会同时进入到同一个函数中去，从而也导致这个问题发生的概率很低。

        而报出Bug来的客户是在美国，网速快得多，会有更大几率同时调用存取Cache的函数，在没有加锁的情况下，就更容易出现Crash啦！

        经验教训：引入多线程机制的时候，一定要仔细查看底层类是否是线程安全的。