Is Golang concurrency unsafe?

Golang, as a relatively young programming language, has attracted more and more attention and love with its rapid development in recent years. Golang's built-in concurrency mechanism makes it favored by many developers, but the use of the concurrency mechanism will cause some hidden dangers, especially when concurrency is unsafe, it may cause a series of problems in the program. This article will explore the reasons and solutions for unsafe concurrency in Golang.

1. Reasons why concurrency is unsafe

1. Race conditions

Race conditions refer to when multiple threads access shared resources, resulting in different results due to different operations Chaos occurs, a situation called a race condition. In Golang, race conditions are more obvious due to the asynchronous execution of coroutines.

2. Data competition

Data competition means that multiple coroutines access the same memory area at the same time, and at least one coroutine is performing a write operation. Due to Golang's concurrency mechanism, different coroutines have different execution times, so multiple coroutines may modify the same memory area at the same time.

3. Deadlock

Deadlock refers to a situation where two or more coroutines are waiting for each other to release resources and cannot continue execution. This situation may occur when using a lock. If the lock is used improperly, a deadlock will occur.

2. Example of unsafe concurrency in Golang

The following is a simple example to explain the problem of unsafe concurrency in Golang:

package main 
import (
   "fmt"
   "sync"
)
var num = 0 
func add(wg *sync.WaitGroup) {
   num++ 
   wg.Done()
}
func main() {
   var wg sync.WaitGroup
   for i := 0; i < 1000; i++ {
      wg.Add(1)
      go add(&wg)
   }
   wg.Wait()
   fmt.Println("num=", num)
}

In this example, we define A global variable num, and use a coroutine to call the add method to increment num 1000 times. Due to the asynchronous execution of coroutines, the execution order of this program is uncertain. If this code runs multiple coroutines at the same time, data competition will occur, and the result of num may not be the 1000 we expect.

3. How to avoid unsafe concurrency in Golang

1. Use locks

Locks are one of the commonly used methods to solve unsafe concurrency problems. Golang provides a variety of locks Implementation, such as sync.Mutex, sync.RWMutex, etc. The use of locks can ensure that only one coroutine can access a certain resource at the same time, thereby avoiding the occurrence of data competition.

Modify the above example and use sync.Mutex to avoid data competition:

package main 
import (
   "fmt"
   "sync"
)
var num = 0 
func add(wg *sync.WaitGroup, lock *sync.Mutex) {
   lock.Lock() 
   num++ 
   lock.Unlock()
   wg.Done()
}
func main() {
   var wg sync.WaitGroup
   var lock sync.Mutex 
   for i := 0; i < 1000; i++ {
      wg.Add(1)
      go add(&wg, &lock)
   }
   wg.Wait()
   fmt.Println("num=", num)
}

In this example, we use sync.Mutex to ensure that modifications to num are atomic. This avoids the occurrence of data races.

2. Use atomic operations

Golang provides a series of atomic operations to ensure that the operation of a certain resource is atomic. Use atomic operations to avoid race conditions, such as AddInt32, AddInt64, SwapInt32, SwapInt64, etc. in the sync/atomic package.

Modify the above example and use atomic operations to avoid data competition:

package main 
import (
   "fmt"
   "sync/atomic"
   "sync"
)
var num int32 
func add(wg *sync.WaitGroup) {
   atomic.AddInt32(&num,1) 
   wg.Done()
}
func main() {
   var wg sync.WaitGroup
   for i := 0; i < 1000; i++ {
      wg.Add(1)
      go add(&wg)
   }
   wg.Wait()
   fmt.Println("num=", num)
}

In this example, we use the AddInt32 function in the sync/atomic package to ensure that the modification to num is atomic. , avoiding the occurrence of race conditions.

3. Use channels

Channels are a very commonly used synchronization mechanism in Golang concurrent programming. Channels can ensure that communication between coroutines is synchronized, thereby avoiding race conditions and data Competition issues.

Modify the above example and use channels to avoid data races:

package main 
import (
   "fmt"
   "sync"
)
func add(wg *sync.WaitGroup, ch chan int) {
   ch <- 1 
   wg.Done()
}
func main() {
   var wg sync.WaitGroup
   ch := make(chan int, 1000)
   for i := 0; i < 1000; i++ {
      wg.Add(1)
      go add(&wg, ch)
   }
   wg.Wait()
   close(ch)
   num := 0 
   for n := range ch {
      num += n
   }
   fmt.Println("num=", num)
}

In this example, we use channels to ensure that modifications to num are synchronized, thereby avoiding the occurrence of data races. .

4. Summary

Golang’s concurrency mechanism is one of its very attractive features, but the use of the concurrency mechanism also brings certain security issues. This article discusses the reasons and solutions for Golang's unsafe concurrency, and provides solutions mainly from the aspects of avoiding data competition, race conditions and deadlocks in concurrency. In the actual programming process, we can choose the appropriate mechanism according to specific needs to ensure the quality and safety of the program.

The above is the detailed content of Is Golang concurrency unsafe?. For more information, please follow other related articles on the PHP Chinese website!