An In-Depth Guide for Using Go sync.Map with Code Sample

In the realm of concurrent programming in Go, managing shared data is a critical task. The Go standard library provides a specialized map type for concurrent use called sync.Map. This article delves into the features, use-cases, and benefits of sync.Map, offering insights into why and how it differs from the conventional Go map.

>> Read more: 

• Sync Package: What Are New Features in Golang sync.Once?
• Guide for Implementing Live Reload Using Golang Air
• Understanding Golang Ordered Map with Code Examples

What is Go sync.Map?

sync.Map is designed to be a high-performance, thread-safe map. It addresses the limitations of standard Go maps in concurrent scenarios. This map type is part of the sync package and provides built-in synchronization to prevent race conditions without the explicit use of mutexes.

When To Use Go sync.Map?

The 6 main problems that sync.Map aims to address include:

• Contention in Concurrent Maps: In a typical concurrent map implemented with a regular map and an external mutex, contention can arise when multiple goroutines try to access the map simultaneously. This contention can lead to performance bottlenecks and may require careful manual locking to ensure correctness.
• Lock Granularity: Fine-grained locking can be challenging when dealing with a regular map. For example, if you want to update only a specific key-value pair without locking the entire map, it requires additional complexity and is error-prone.
• Lazy Initialization: In some scenarios, you might want to lazily initialize map entries rather than initializing the entire map before use. Handling lazy initialization in a thread-safe manner with a regular map and external locks can be cumbersome.
• Non-blocking Operations:sync.Map provides non-blocking operations such as Load, Store, and Delete. This can be beneficial in scenarios where avoiding blocking and contention is crucial for performance.
• Efficient Reads and Infrequent Writes:sync.Map is optimized for scenarios where there are many reads and infrequent writes. It is designed to efficiently handle situations where the majority of operations are read operations.
• Automatic Handling of Map Copying: Internally, sync.Map handles the copying of map data when necessary. It automatically promotes the dirty map to the read map when the number of misses (operations that require locking) reaches a threshold. This helps in optimizing the overall performance.

Overall, sync.Map simplifies concurrent access to maps by providing a built-in mechanism for safe and efficient concurrent reads and writes. It is particularly well-suited for scenarios where contention is expected to be a bottleneck, and a balance between simplicity and performance is crucial.

Here is a simple example demonstrating the basic usage of Golang sync.Map:

package main

import (
	"fmt"
	"sync"
)

func main() {
	var myMap sync.Map

	// Store a key-value pair
	myMap.Store("key", "value")

	// Load a value for a key
	value, ok := myMap.Load("key")
	if ok {
		fmt.Println("Value:", value)
	}

	// Delete a key
	myMap.Delete("key")
}

How Does Golang sync.Map Work?

The sync.Map data structure in Go consists of two main components: read and dirty. These represent two maps used for efficient and concurrent access.

Underlying Structure

type Map struct {
   mu     Mutex
   read   atomic.Value // readOnly
   dirty  map[interface{}]*entry
   misses int
}

type readOnly struct {
   m       map[interface{}]*entry
   amended bool
}

• mu: A mutex used to protect access to read and dirty.
• read: A read-only data structure supporting concurrent reads using atomic operations. It stores a readOnly structure, which is a native map. The amended attribute marks whether the read and dirty data are consistent.
• dirty: A native map for reading and writing data, requiring locking to ensure data security.
• misses: A counter tracking how many times the read operation fails.

Entry Structure

type entry struct {
   p unsafe.Pointer // *interface{}
}

• It contains a pointer p that points to the value stored for the element (key).

Reading Process

• When reading from sync.Map, it checks if the required elements are in read.
• If present, it reads the data atomically; if not, it checks read.readOnly. If dirty contains read.readOnly.m, indicating an inconsistency (amended is true), it searches for data in dirty.
• The ingenious design of read acting as a cache layer, combined with the amended attribute, eliminates locks in each read operation, ensuring high performance.

Writing Process

• For storing or updating an element, it first checks if the element exists in read. If yes, it attempts to store the value; if not, it proceeds to the dirty process.
• In the dirty process, a mutex lock is acquired for data security. The element is then stored or updated in the dirty map.

Deletion Process

• Deletion checks if the element exists in read. If yes, it marks it as expunged (deleted state) efficiently.
• If not, and if dirty is inconsistent with read (amended is true), it locks the mutex and performs a double-check. If the element is still absent in read, it marks the deletion in the dirty map.

Sample Code of Golang sync.Map

package main

import (
	"fmt"
	"sync"
)

func main() {
	// Create a new sync.Map
	var m sync.Map

	// Number of goroutines for concurrent operations
	numGoroutines := 5

	// Use a WaitGroup to wait for all goroutines to finish
	var wg sync.WaitGroup
	wg.Add(numGoroutines)

	// Writing goroutines
	for i := 0; i < numGoroutines; i++ {
		go func(id int) {
			defer wg.Done()

			// Store key-value pair
			m.Store(id, id)

			// Load and print the value
			if value, ok := m.Load(id); ok {
				fmt.Printf("Goroutine %d: Key %d - Value %d\n", id, id, value)
			}
		}(i)
	}

	// Wait for all writing goroutines to finish
	wg.Wait()
	
	// Reading goroutines
	wg.Add(numGoroutines)
	for i := 0; i < numGoroutines; i++ {
		go func(id int) {
			defer wg.Done()
			// Load and print the value
			if value, ok := m.Load(id); ok {
				fmt.Printf("Reading Goroutine %d: Key %d - Value %d\n", id, id, value)
			} else {
				fmt.Printf("Reading Goroutine %d: Key %d not found\n", id, id)
			}
		}(i)
	}

	// Wait for all reading goroutines to finish
	wg.Wait()
}

Result:

Goroutine 4: Key 4 - Value 4
Goroutine 0: Key 0 - Value 0
Goroutine 2: Key 2 - Value 2
Goroutine 3: Key 3 - Value 3
Goroutine 1: Key 1 - Value 1
Reading Goroutine 4: Key 4 - Value 4
Reading Goroutine 2: Key 2 - Value 2
Reading Goroutine 1: Key 1 - Value 1
Reading Goroutine 0: Key 0 - Value 0
Reading Goroutine 3: Key 3 - Value 3

Let's break down the code step by step:

Step 1: Create sync.Map and WaitGroup

// Create a new sync.Map
var m sync.Map

// Number of goroutines for concurrent operations
numGoroutines := 5

// Use a WaitGroup to wait for all goroutines to finish
var wg sync.WaitGroup
wg.Add(numGoroutines)

• m is an instance of sync.Map that we'll use for concurrent read and write operations.
• numGoroutines specifies the number of goroutines for concurrent operations.
• wg is a sync.WaitGroup used to wait for all goroutines to finish.

Step 2: Writing Goroutines

// Writing goroutines
for i := 0; i < numGoroutines; i++ {
  go func(id int) {
      defer wg.Done()

      // Store key-value pair
      m.Store(id, id)

      // Load and print the value
      if value, ok := m.Load(id); ok {
          fmt.Printf("Goroutine %d: Key %d - Value %d\n", id, id, value)
      }
  }(i)
}

• A loop creates and launches goroutines.
• Each goroutine stores a key-value pair in the sync.Map.
• It then loads and prints the value associated with the key.

Step 3: Reading Goroutines

// Reading goroutines
wg.Add(numGoroutines)
for i := 0; i < numGoroutines; i++ {
go func(id int) {
  defer wg.Done()

  // Load and print the value
  if value, ok := m.Load(id); ok {
      fmt.Printf("Reading Goroutine %d: Key %d - Value %d\n", id, id, value)
  } else {
      fmt.Printf("Reading Goroutine %d: Key %d not found\n", id, id)
  }
}(i)
}

• Another set of goroutines is created for reading.
• Each reading goroutine loads and prints the value associated with the key.
• If the key is not found, it prints a message indicating that.

The overall purpose of this code is to demonstrate the concurrent usage of a sync.Map where multiple goroutines perform both write and read operations concurrently, showcasing how synchronization is handled by the sync.Map data structure.

Implement Caching Using sync.Map

Now that we understand the benefits of using sync.Map for caching, let's dive into implementing it in our Go application. First, let's create a simple cache structure:

package main

import (
    "sync"
    "fmt"
    "time"
    "math/rand"
)

// Cache struct using sync.Map
type Cache struct {
    store sync.Map
}

// Set a value in the cache
func (c *Cache) Set(key string, value interface{}) {
    c.store.Store(key, value)
}

// Get a value by key from the cache
func (c *Cache) Get(key string) (interface{}, bool) {
    val, ok := c.store.Load(key)
    return val, ok
}

// Delete a value by key from the cache
func (c *Cache) Delete(key string) {
    c.store.Delete(key)
}

func accessCache(c *Cache, id int) {
    key := fmt.Sprintf("key%d", id)
    value := rand.Intn(100)

    // Set a value in the cache
    c.Set(key, value)
    fmt.Printf("Goroutine %d set %s to %d\n", id, key, value)

    // Get a value from the cache
    if val, ok := c.Get(key); ok {
        fmt.Printf("Goroutine %d got %s: %d\n", id, key, val)
    }

    // Sleep to simulate work
    time.Sleep(time.Millisecond * time.Duration(rand.Intn(100)))

    // Delete the key
    c.Delete(key)
    fmt.Printf("Goroutine %d deleted %s\n", id, key)
}

func main() {
    c := Cache{}

    // Launch multiple goroutines to access the cache
    for i := 0; i < 10; i++ {
        go accessCache(&c, i)
    }

    // Wait for all goroutines to finish
    time.Sleep(5 * time.Second)
}

• We've created a function accessCache, which each goroutine will execute. This function simulates setting, getting, and deleting values in the cache.
• Each goroutine works with a unique key but shares the same cache instance.
• sync.Map efficiently handles concurrent operations on the cache without needing explicit locks or risking race conditions.
• We use time.Sleep to simulate some delay, representing real-world processing time.

This example demonstrates the advantage of sync.Map in a concurrent setting. The sync.Map type manages the complexity of synchronization internally, making it easier and safer to use in concurrent applications compared to a regular map with manual locking.

What Happen If Not Use sync.Map in Concurrent Environment?

When using a regular map in a concurrent environment without proper synchronization, you may encounter various race conditions and data inconsistencies. Here are some common issues that can arise:

• Race Conditions: Concurrent reads and writes to a standard map without proper synchronization can result in race conditions. For example, if one goroutine is writing to the map while another is reading from it, the data may become inconsistent.
• Data Corruption: Concurrent writes to a map without synchronization can lead to data corruption. If multiple goroutines are writing to the same key simultaneously, the final value of the key may be unpredictable.
• Deadlocks: If multiple goroutines attempt to read and write to a map simultaneously without synchronization, deadlocks may occur. Deadlocks happen when goroutines are waiting for each other to release locks, resulting in a program that hangs.
• Inconsistent Reads: Without proper synchronization, concurrent reads may produce inconsistent results. For instance, one goroutine might read a value that is in the process of being updated by another goroutine, leading to incorrect or outdated data.
• Panics: Concurrent modification of a standard map can cause panics due to concurrent map writes. The Go runtime may detect data races and panic to avoid unpredictable behavior.

Benefits of Golang sync.Map Over Standard Go Maps

Reduced Lock Contention

sync.Map reduces lock contention among goroutines accessing the map concurrently.

• Standard Go Maps: In a concurrent setting, standard Go maps require explicit locking (typically using sync.Mutex or sync.RWMutex) to synchronize access. This can lead to lock contention, where multiple goroutines compete to acquire the lock, leading to a potential decrease in performance, especially in high-load scenarios.
• sync.Map: It is designed to handle frequent concurrent access with minimal lock contention. The internal implementation of sync.Map uses a combination of fine-grained locking and lock-free read paths. This design reduces the time goroutines spend waiting for locks, thus improving concurrent performance.

Atomic Operations

• Standard Go Maps: Performing atomic operations with standard Go maps involves manually managing locks to ensure safe concurrent access, which can be error-prone and complex.
• sync.Map: It provides built-in methods like Load, Store, Delete, LoadOrStore, and LoadAndDelete, which are inherently atomic. These methods manage all the necessary locking and synchronization internally, ensuring that operations are thread-safe and free from common concurrency issues like race conditions.

Improved Performance

Optimized for scenarios where entries are only written once but read many times.

• Write-Once, Read-Many: sync.Map is particularly optimized for use cases where the map is populated once (or infrequently updated) but read many times, which is a common pattern in caching scenarios and read-heavy workloads. In these situations, sync.Map can outperform standard maps with mutexes because of its efficient handling of concurrent read operations.
• Dynamic Key Spaces: For maps with a dynamic set of keys (frequent insertions and deletions), the standard Go map with proper locking might still be more performant. The overhead of sync.Map's internal mechanisms can be higher in such cases. Performance testing in the specific context of the application is crucial to make the right choice.

In practice, using sync.Map makes sense when your application involves concurrent operations on a map and fits the optimized use case of write-once-read-many. It reduces the complexity of managing locks and improves readability and maintainability of the code, all while providing performance benefits in the right scenarios. However, it's always recommended to benchmark sync.Map against a standard map with mutexes in your specific use case to make an informed decision.

Comparison of sync.Map with Traditional Maps

sync.Map shines in specific scenarios but isn't universally superior to traditional Go maps. It's particularly advantageous when dealing with read-heavy operations and stable key sets - where keys are not frequently added or removed.

In contrast, for use cases involving frequent changes to the map's keys, a standard Go map combined with a mutex might outperform sync.Map. This is due to the overhead associated with sync.Map's internal mechanisms designed to optimize concurrent read access.

Best Practices for Using Go sync.Map

• Ideal Use Case: sync.Map is best used in situations where multiple goroutines need to read, write, and update keys and values concurrently. It's particularly effective in environments where the map is populated once and read many times, such as caches.
• Avoid for Dynamic Key Spaces: If your map experiences frequent key changes (additions or deletions), sync.Map may not be the most efficient choice. In such cases, the overhead of sync.Map's concurrency-safe features could potentially hinder performance.
• Performance Benchmarking: Always benchmark sync.Map against a standard Go map with mutexes in your specific application context. This helps in making an informed decision about whether the overhead of sync.Map is justified by the performance gains in your particular use case.

>> Read more:

• Instruction For Using Golang Generics With Code Examples
• Comprehending Arrays and Slices in Go
• Detailed Guide for Simplifying Testing with Golang Testify
• Golang Struct Mastery: Deep Dive for Experienced Developers

Conclusion

Using sync.Map helps to address these issues by providing built-in synchronization mechanisms, ensuring safe concurrent access to the map. It eliminates the need for external locks and simplifies the process of handling concurrent reads and writes. sync.Map is specifically designed for scenarios where multiple goroutines access and modify the map concurrently, making it a safer choice for concurrent programming.