go语言最重要的特点就是原生支持并发————goroutine。而用到并发，就不得不考虑数据安全的问题。Go语言里有两种方式实现并发安全。

以下是go官网上对于内存模型的建议:

Advice
Programs that modify data being simultaneously accessed by multiple goroutines must serialize such access.
To serialize access, protect the data with channel operations or other synchronization primitives such as those in the sync and sync/atomic packages.
If you must read the rest of this document to understand the behavior of your program, you are being too clever. Don’t be clever.

1. sync/atomic

sync/atomic包提供了底层的原子级内存操作。该包的函数分为四个系列: Load，Store，Add，Swap，CompareAndSwap，分别用来进行整形变量的加载，保存，加减，交换和比较交换操作。
这些函数必须谨慎地保证正确使用。除了某些特殊的底层应用，使用通道或者sync包的函数/类型实现同步更好。

2. sync

2.1 什么情况下要使用锁

当可能存在以下情况：同时有多个线程访问同一段内存，且其中至少有一个线程的操作是写操作。
满足以上条件，就应该果断加锁。加锁的操作是几十纳秒级别的，开销基本可以忽略。而如果没有加锁导致数据不一致甚至crash，损失就大了。以上条件对使用atomic包依然成立。

2.2 example

sync包的锁包括互斥锁和读写互斥锁。
简单写了一个读写互斥锁的例子，需要注意的是，不仅写的时候要加锁(或使用atomic操作)，读的时候也要加锁(或使用atomic操作)。

type smtx struct {
    lock  sync.RWMutex
    data  string
}

var s smtx

func write() {
    s.Lock()
    defer s.Unlock()
    s.data += "a"

}

func read() {
    s.RLock()
    defer s.RUnlock()
    fmt.Println(s.data)
}

3. channel

Go语言有一句流行的黑话：不要通过共享内存进行通信, 通过通信共享内存 (Don’t communicate by sharing memory, insted share memory by communicating)。通过通信来共享内存，可以更大程度的解耦代码，提高代码的可读性和可维护性。虽然增加了一点内存开销，但是大大降低编程复杂度。
说一句题外话，微服务架构，也是利用消息队列来实现模块之间的解偶。和这句话有相通之处。
channel本质上就是通过内存队列，一次性只处理一个消息，从而实现了访问的序列化，避免了数据竞争(data race)。

很多时候，编译器会做一些神奇的优化，导致意想不到的数据冲突，所以，只要满足“同时有多个线程访问同一段内存，且其中至少有一个线程的操作是写操作”这一条件，就需要作并发安全方面的处理。
最后，推荐一篇关于数据竞争文章, 说明了，即使在所谓良性数据竞争，也可能出问题。