Catena （時序儲存引擎）中有一個函式的實現備受爭議，它從 map 中根據指定的 name 獲取一個 metricSource。每一次插入操作都會至少呼叫一次這個函式，現實場景中該函式呼叫更是頻繁，並且是跨多個協程的，因此我們必須要考慮同步。

該函式從 map[string]*metricSource 中根據指定的 name 獲取一個指向 metricSource 的指標，如果獲取不到則建立一個並返回。其中要注意的關鍵點是我們只會對這個 map 進行插入操作。

簡單實現如下：（為節省篇幅，省略了函式頭和返回，只貼重要部分）

var source *memorySource
var present bool

p.lock.Lock() // lock the mutex
defer p.lock.Unlock() // unlock the mutex at the end

if source, present = p.sources[name]; !present {
	// The source wasn't found, so we'll create it.
	source = &memorySource{
		name: name,
		metrics: map[string]*memoryMetric{},
	}

	// Insert the newly created *memorySource.
	p.sources[name] = source
}

經測試，該實現大約可以達到 1,400,000 插入/秒（通過協程併發呼叫，GOMAXPROCS 設定為 4）。看上去很快，但實際上它是慢於單個協程的，因為多個協程間存在鎖競爭。

我們簡化一下情況來說明這個問題，假設兩個協程分別要獲取“a”、“b”，並且“a”、“b”都已經存在於該 map 中。上述實現在執行時，一個協程獲取到鎖、拿指標、解鎖、繼續執行，此時另一個協程會被卡在獲取鎖。等待鎖釋放是非常耗時的，並且協程越多效能越差。

讓它變快的方法之一是移除鎖控制，並保證只有一個協程訪問這個 map。這個方法雖然簡單，但沒有伸縮性。下面我們看看另一種簡單的方法，並保證了執行緒安全和伸縮性。 

var source *memorySource
var present bool

if source, present = p.sources[name]; !present { // added this line
	// The source wasn't found, so we'll create it.

	p.lock.Lock() // lock the mutex
	defer p.lock.Unlock() // unlock at the end

	if source, present = p.sources[name]; !present {
		source = &memorySource{
			name: name,
			metrics: map[string]*memoryMetric{},
		}

		// Insert the newly created *memorySource.
		p.sources[name] = source
	}
	// if present is true, then another goroutine has already inserted
	// the element we want, and source is set to what we want.

} // added this line

// Note that if the source was present, we avoid the lock completely!

該實現可以達到 5,500,000 插入/秒，比第一個版本快 3.93 倍。有 4 個協程在跑測試，結果數值和預期是基本吻合的。

這個實現是 ok 的，因為我們沒有刪除、修改操作。在 CPU 快取中的指標地址我們可以安全使用，不過要注意的是我們還是需要加鎖。如果不加，某協程在建立插入 source 時另一個協程可能已經正在插入，它們會處於競爭狀態。這個版本中我們只是在很少情況下加鎖，所以效能提高了很多