先上实例代码，后面再来详细讲解。
上面代码中的 var list []int 就是我们这次验证的主角，slice。
主程序发起1w个并发，不断的往slice中填充数据。
不安全的方式，将新数据直接 append 到slice中。
安全的方式，需要在 append 之前加锁，然后操作完再解锁。
本地计算机是4核i5处理器，并发运行1w个协程，看到下面的执行结果，和大家预期的一样吗？
list加1w个数据，但是最后只看到9989个，不足1w个的原因就是因为线程不安全，造成数据的丢失。
之前的一篇文章《记录一次在github上帮iris找bug和修复的经历(Go最好的Web框架之一)》，iris中websocket的线程安全性问题，就是因为没有考虑slice的并发读写问题，原因和结果跟上面的实例代码是一样的。
那么，为什么会出现这样的线程安全性问题呢？
并发读写在单线程运行时就不会有这种线程安全性问题。
而现在多核CPU，多线程的程序，这种问题就会越来越突出。
我们来思考下：
线程A， list=append(list,1) ，这时候 list={1}，那么新的list就是list={1,1}
线程B， list=append(list,1) ，这时候 list={1}，那么新的list就是list={1,1}
发现了没有，线程A和线程B是同时运行（多核并行运算），而且拿到的list变量也是完全一样的值，那么各自计算之后，更新list的值也是完全一样。
不论是线程A先写入内存，还是线程B先写入内存，肯定就有一次写入会覆盖之前一次写入，最终的结果是list={1,1}，而不是list={1,1,1}。
上面就是因为线程不安全，导致少写入了一个数据。
再看下加锁的情况下，为什么就安全了呢？
我们再来思考下：
线程A， lock, list=append(list,1), unlock ，这时候 list={1}，那么新的list就是 list={1,1}
线程B， lock/等待, list=append(list,1), unlock , 这时候 list={1,1}，那么新的list就是 list={1,1,1}
因为append的前后有一个加锁、解锁的指令，这样就避免了多线程同时并行执行 list=append(list,1) 的操作。
不存在并行运算，那么并发操作也就是安全了。
关于并行、并发的概念，大家可以参考之前的系列文章。
这里保证 slice 线程安全的方法是用互斥锁，也可以考虑把数据写入、更新的代码封装到一个 channel 中，有一个专门的协程来单独维护 slice 的数据更新。如：
由于 slice 不存在并发读写的冲突，所以在读取的时候可以省去加锁的操作，也就不用考虑读写锁了。
后面的文章，我们再来一起看下map的线程安全性问题，跟slice还是有很大不同哟。
推荐阅读：