偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

Go：有了 Sync 為什么還有 Atomic？

作者：程序員ug
開(kāi)發(fā) 后端
Go 是一種擅長(zhǎng)并發(fā)的語(yǔ)言，啟動(dòng)新的 goroutine 就像輸入 “go” 一樣簡(jiǎn)單。隨著你發(fā)現(xiàn)自己構(gòu)建的系統(tǒng)越來(lái)越復(fù)雜，正確保護(hù)對(duì)共享資源的訪(fǎng)問(wèn)以防止競(jìng)爭(zhēng)條件變得極其重要。此類(lèi)資源可能包括可即時(shí)更新的配置(例如功能標(biāo)志)、內(nèi)部狀態(tài)(例如斷路器狀態(tài))等。

[[438792]]

Go 是一種擅長(zhǎng)并發(fā)的語(yǔ)言，啟動(dòng)新的 goroutine 就像輸入 “go” 一樣簡(jiǎn)單。隨著你發(fā)現(xiàn)自己構(gòu)建的系統(tǒng)越來(lái)越復(fù)雜，正確保護(hù)對(duì)共享資源的訪(fǎng)問(wèn)以防止競(jìng)爭(zhēng)條件變得極其重要。此類(lèi)資源可能包括可即時(shí)更新的配置(例如功能標(biāo)志)、內(nèi)部狀態(tài)(例如斷路器狀態(tài))等。

01 什么是競(jìng)態(tài)條件?

對(duì)于大多數(shù)讀者來(lái)說(shuō)，這可能是基礎(chǔ)知識(shí)，但由于本文的其余部分取決于對(duì)競(jìng)態(tài)條件的理解，因此有必要進(jìn)行簡(jiǎn)短的復(fù)習(xí)。競(jìng)態(tài)條件是一種情況，在這種情況下，程序的行為取決于其他不可控事件的順序或時(shí)間。在大多數(shù)情況下，這種情況是一個(gè)錯(cuò)誤，因?yàn)榭赡軙?huì)發(fā)生不希望的結(jié)果。

舉個(gè)具體的例子或許更容易理解：

  1. // race_condition_test.go 
  2. package main 
  3.  
  4. import ( 
  5.  "fmt" 
  6.  "sort" 
  7.  "sync" 
  8.  "testing" 
  9. ) 
  10.  
  11. func Test_RaceCondition(t *testing.T) { 
  12.  var s = make([]int, 0) 
  13.  
  14.  wg := sync.WaitGroup{} 
  15.  
  16.  // spawn 10 goroutines to modify the slice in parallel 
  17.  for i := 0; i < 10; i++ { 
  18.   wg.Add(1) 
  19.   go func(i int) { 
  20.    defer wg.Done() 
  21.    s = append(s, i) //add a new item to the slice 
  22.   }(i) 
  23.  } 
  24.  
  25.  wg.Wait() 
  26.   
  27.  sort.Ints(s) //sort the response to have comparable results 
  28.  fmt.Println(s) 
  29. } 

執(zhí)行一：

  1. $ go test -v race_condition_test.go 
  2. === RUN   Test_RaceCondition 
  3. [0 1 2 3 4 5 6 7 8 9] 
  4. --- PASS: Test_RaceCondition (0.00s) 

這里看起來(lái)一切都很好。這是我們預(yù)期的輸出。該程序迭代了 10 次，并在每次迭代時(shí)將索引添加到切片中。

執(zhí)行二：

  1. === RUN Test_RaceCondition 
  2.  
  3. [0 3] 
  4.  
  5. --- PASS: Test_RaceCondition (0.00s) 

等等，這里發(fā)生了什么?這次我們的響應(yīng)切片中只有兩個(gè)元素。這是因?yàn)榍衅膬?nèi)容 s 在加載和修改之間發(fā)生了變化，導(dǎo)致程序覆蓋了一些結(jié)果。這種特殊的競(jìng)態(tài)條件是由數(shù)據(jù)競(jìng)爭(zhēng)引起的，在這種情況下，多個(gè) goroutine 嘗試同時(shí)訪(fǎng)問(wèn)特定的共享變量，并且這些 goroutine 中的至少一個(gè)嘗試修改它。(注意，以上結(jié)果并非一定如此，每次運(yùn)行結(jié)果可能都不相同)

如果你使用 -race 標(biāo)志執(zhí)行測(cè)試，go 甚至?xí)嬖V你存在數(shù)據(jù)競(jìng)爭(zhēng)并幫助你準(zhǔn)確定位：

  1. $ go test race_condition_test.go -race 
  2.  
  3. ================== 
  4. WARNING: DATA RACE 
  5. Read at 0x00c000132048 by goroutine 9: 
  6.   command-line-arguments.Test_RaceCondition.func1() 
  7.       /home/sfinlay/go/src/benchmarks/race_condition_test.go:20 +0xb4 
  8.   command-line-arguments.Test_RaceCondition·dwrap·1() 
  9.       /home/sfinlay/go/src/benchmarks/race_condition_test.go:21 +0x47 
  10.  
  11. Previous write at 0x00c000132048 by goroutine 8: 
  12.   command-line-arguments.Test_RaceCondition.func1() 
  13.       /home/sfinlay/go/src/benchmarks/race_condition_test.go:20 +0x136 
  14.   command-line-arguments.Test_RaceCondition·dwrap·1() 
  15.       /home/sfinlay/go/src/benchmarks/race_condition_test.go:21 +0x47 
  16.  
  17. Goroutine 9 (running) created at: 
  18.   command-line-arguments.Test_RaceCondition() 
  19.       /home/sfinlay/go/src/benchmarks/race_condition_test.go:18 +0xc5 
  20.   testing.tRunner() 
  21.       /usr/local/go/src/testing/testing.go:1259 +0x22f 
  22.   testing.(*T).Run·dwrap·21() 
  23.       /usr/local/go/src/testing/testing.go:1306 +0x47 
  24.  
  25. Goroutine 8 (finished) created at: 
  26.   command-line-arguments.Test_RaceCondition() 
  27.       /home/sfinlay/go/src/benchmarks/race_condition_test.go:18 +0xc5 
  28.   testing.tRunner() 
  29.       /usr/local/go/src/testing/testing.go:1259 +0x22f 
  30.   testing.(*T).Run·dwrap·21() 
  31.       /usr/local/go/src/testing/testing.go:1306 +0x47 
  32. ================== 

02 并發(fā)控制

保護(hù)對(duì)這些共享資源的訪(fǎng)問(wèn)通常涉及常見(jiàn)的內(nèi)存同步機(jī)制，例如通道或互斥鎖。

這是將競(jìng)態(tài)條件調(diào)整為使用互斥鎖的相同測(cè)試用例：

  1. func Test_NoRaceCondition(t *testing.T) { 
  2.  var s = make([]int, 0) 
  3.  
  4.  m := sync.Mutex{} 
  5.  wg := sync.WaitGroup{} 
  6.  
  7.  // spawn 10 goroutines to modify the slice in parallel 
  8.  for i := 0; i < 10; i++ { 
  9.   wg.Add(1) 
  10.   go func(i int) { 
  11.    m.Lock() 
  12.    defer wg.Done() 
  13.    defer m.Unlock() 
  14.    s = append(s, i) 
  15.   }(i) 
  16.  } 
  17.  
  18.  wg.Wait() 
  19.  
  20.  sort.Ints(s) //sort the response to have comparable results 
  21.  fmt.Println(s) 
  22. } 

這次它始終返回所有 10 個(gè)整數(shù)，因?yàn)樗_保每個(gè) goroutine 僅在沒(méi)有其他人執(zhí)行時(shí)才讀寫(xiě)切片。如果第二個(gè) goroutine 同時(shí)嘗試獲取鎖，它必須等到前一個(gè) goroutine 完成(即直到它解鎖)。

然而，對(duì)于高吞吐量系統(tǒng)，性能變得非常重要，因此減少鎖爭(zhēng)用(即一個(gè)進(jìn)程或線(xiàn)程試圖獲取另一個(gè)進(jìn)程或線(xiàn)程持有的鎖的情況)變得更加重要。執(zhí)行此操作的最基本方法之一是使用讀寫(xiě)鎖 ( sync.RWMutex) 而不是標(biāo)準(zhǔn) sync.Mutex，但是 Go 還提供了一些原子內(nèi)存原語(yǔ)即 atomic 包。

03 原子

Go 的 atomic 包提供了用于實(shí)現(xiàn)同步算法的低級(jí)原子內(nèi)存原語(yǔ)。這聽(tīng)起來(lái)像是我們需要的東西，所以讓我們嘗試用 atomic 重寫(xiě)該測(cè)試：

  1. import "sync/atomic" 
  2.  
  3. func Test_RaceCondition_Atomic(t *testing.T) { 
  4.  var s = atomic.Value{} 
  5.  s.Store([]int{}) // store empty slice as the base 
  6.  
  7.  wg := sync.WaitGroup{} 
  8.  
  9.  // spawn 10 goroutines to modify the slice in parallel 
  10.  for i := 0; i < 10; i++ { 
  11.   wg.Add(1) 
  12.   go func(i int) { 
  13.    defer wg.Done() 
  14.    s1 := s.Load().([]int) 
  15.    s.Store(append(s1, i)) //replace the slice with a new one containing the new item 
  16.   }(i) 
  17.  } 
  18.  
  19.  wg.Wait() 
  20.  
  21.  s1 := s.Load().([]int) 
  22.  sort.Ints(s1) //sort the response to have comparable results 
  23.  fmt.Println(s1) 
  24. } 

執(zhí)行結(jié)果：

  1. === RUN Test_RaceCondition_Atomic 
  2.  
  3. [1 3] 
  4.  
  5. --- PASS: Test_RaceCondition_Atomic (0.00s) 

什么?這和我們之前遇到的問(wèn)題完全一樣，那么這個(gè)包有什么好處呢?

04 讀取-復(fù)制-更新

atomic 不是靈丹妙藥，它顯然不能替代互斥鎖，但是當(dāng)涉及到可以使用讀取-復(fù)制-更新[1]模式管理的共享資源時(shí)，它非常出色。在這種技術(shù)中，我們通過(guò)引用獲取當(dāng)前值，當(dāng)我們想要更新它時(shí)，我們不修改原始值，而是替換指針(因此沒(méi)有人訪(fǎng)問(wèn)另一個(gè)線(xiàn)程可能訪(fǎng)問(wèn)的相同資源)。前面的示例無(wú)法使用此模式實(shí)現(xiàn)，因?yàn)樗鼞?yīng)該隨著時(shí)間的推移擴(kuò)展現(xiàn)有資源而不是完全替換其內(nèi)容，但在許多情況下，讀取-復(fù)制-更新是完美的。

這是一個(gè)基本示例，我們可以在其中獲取和存儲(chǔ)布爾值(例如，對(duì)于功能標(biāo)志很有用)。在這個(gè)例子中，我們正在執(zhí)行一個(gè)并行基準(zhǔn)測(cè)試，比較原子和讀寫(xiě)互斥：

  1. package main 
  2.  
  3. import ( 
  4.  "sync" 
  5.  "sync/atomic" 
  6.  "testing" 
  7. ) 
  8.  
  9. type AtomicValue struct{ 
  10.  value atomic.Value 
  11. } 
  12.  
  13. func (b *AtomicValue) Get() bool { 
  14.  return b.value.Load().(bool) 
  15. } 
  16.  
  17. func (b *AtomicValue) Set(value bool) { 
  18.  b.value.Store(value) 
  19. } 
  20.  
  21. func BenchmarkAtomicValue_Get(b *testing.B) { 
  22.  atomB := AtomicValue{} 
  23.  atomB.value.Store(false) 
  24.  
  25.  b.RunParallel(func(pb *testing.PB) { 
  26.   for pb.Next() { 
  27.    atomB.Get() 
  28.   } 
  29.  }) 
  30. } 
  31.  
  32. /************/ 
  33.  
  34. type MutexBool struct { 
  35.  mutex sync.RWMutex 
  36.  flag  bool 
  37. } 
  38.  
  39. func (mb *MutexBool) Get() bool { 
  40.  mb.mutex.RLock() 
  41.  defer mb.mutex.RUnlock() 
  42.  return mb.flag 
  43. } 
  44.  
  45. func BenchmarkMutexBool_Get(b *testing.B) { 
  46.  mb := MutexBool{flag: true} 
  47.  
  48.  b.RunParallel(func(pb *testing.PB) { 
  49.   for pb.Next() { 
  50.    mb.Get() 
  51.   } 
  52.  }) 
  53. } 

結(jié)果：

  1. cpu: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz 
  2. BenchmarkAtomicValue_Get 
  3. BenchmarkAtomicValue_Get-8    1000000000          0.5472 ns/op 
  4. BenchmarkMutexBool_Get 
  5. BenchmarkMutexBool_Get-8      24966127            48.80 ns/op 

結(jié)果很清楚。atomic 的速度提高了 89 倍以上。并且可以通過(guò)使用更原始的類(lèi)型來(lái)進(jìn)一步改進(jìn)：

  1. type AtomicBool struct{ flag int32 } 
  2.  
  3. func (b *AtomicBool) Get() bool { 
  4.  return atomic.LoadInt32(&(b.flag)) != 0 
  5. } 
  6.  
  7. func (b *AtomicBool) Set(value bool) { 
  8.  var i int32 = 0 
  9.  if value { 
  10.   i = 1 
  11.  } 
  12.  atomic.StoreInt32(&(b.flag), int32(i)) 
  13. } 
  14.  
  15. func BenchmarkAtomicBool_Get(b *testing.B) { 
  16.  atomB := AtomicBool{flag: 1} 
  17.  
  18.  b.RunParallel(func(pb *testing.PB) { 
  19.   for pb.Next() { 
  20.    atomB.Get() 
  21.   } 
  22.  }) 
  23. } 
  24. cpu: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz 
  25. BenchmarkAtomicBool_Get 
  26. BenchmarkAtomicBool_Get-8     1000000000          0.3161 ns/op 

此版本比互斥鎖版本快 154 倍以上。

寫(xiě)操作也顯示出明顯的差異(盡管規(guī)模并不那么令人印象深刻)：

  1. func BenchmarkAtomicBool_Set(b *testing.B) { 
  2.  atomB := AtomicBool{flag: 1} 
  3.  
  4.  b.RunParallel(func(pb *testing.PB) { 
  5.   for pb.Next() { 
  6.    atomB.Set(true) 
  7.   } 
  8.  }) 
  9. } 
  10.  
  11. /************/ 
  12.  
  13. func BenchmarkAtomicValue_Set(b *testing.B) { 
  14.  atomB := AtomicValue{} 
  15.  atomB.value.Store(false) 
  16.  
  17.  b.RunParallel(func(pb *testing.PB) { 
  18.   for pb.Next() { 
  19.    atomB.Set(true) 
  20.   } 
  21.  }) 
  22. } 
  23.  
  24. /************/ 
  25.  
  26. func BenchmarkMutexBool_Set(b *testing.B) { 
  27.  mb := MutexBool{flag: true} 
  28.  
  29.  b.RunParallel(func(pb *testing.PB) { 
  30.   for pb.Next() { 
  31.    mb.Set(true) 
  32.   } 
  33.  }) 
  34. } 

結(jié)果：

  1. cpu: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz 
  2. BenchmarkAtomicBool_Set 
  3. BenchmarkAtomicBool_Set-8     64624705         16.79 ns/op 
  4. BenchmarkAtomicValue_Set 
  5. BenchmarkAtomicValue_Set-8    47654121         26.43 ns/op 
  6. BenchmarkMutexBool_Set 
  7. BenchmarkMutexBool_Set-8      20124637         66.50 ns/op 

在這里我們可以看到 atomic 在寫(xiě)入時(shí)比在讀取時(shí)慢得多，但仍然比互斥鎖快得多。有趣的是，我們可以看到互斥鎖讀取和寫(xiě)入之間的差異不是很明顯(慢 30%)。盡管如此， atomic 仍然表現(xiàn)得更好(比互斥鎖快 2-4 倍)。

05 為什么 atomic 這么快?

簡(jiǎn)而言之，原子操作很快，因?yàn)樗鼈円蕾?lài)于原子 CPU 指令而不是依賴(lài)外部鎖。使用互斥鎖時(shí)，每次獲得鎖時(shí)，goroutine 都會(huì)短暫暫停或中斷，這種阻塞占使用互斥鎖所花費(fèi)時(shí)間的很大一部分。原子操作可以在沒(méi)有任何中斷的情況下執(zhí)行。

06 atomic 總是答案嗎?

正如我們?cè)谝粋€(gè)早期示例中已經(jīng)證明的那樣，atomic 無(wú)法解決所有問(wèn)題，某些操作只能使用互斥鎖來(lái)解決。

考慮以下示例，該示例演示了我們使用 map 作為內(nèi)存緩存的常見(jiàn)模式：

  1. package main 
  2.  
  3. import ( 
  4.  "sync" 
  5.  "sync/atomic" 
  6.  "testing" 
  7. ) 
  8.  
  9. //Don't use this implementation! 
  10. type AtomicCacheMap struct { 
  11.  value atomic.Value //map[int]int 
  12. } 
  13.  
  14. func (b *AtomicCacheMap) Get(key int) int { 
  15.  return b.value.Load().(map[int]int)[key] 
  16. } 
  17.  
  18. func (b *AtomicCacheMap) Set(key, value int) { 
  19.  oldMap := b.value.Load().(map[int]int) 
  20.  newMap := make(map[int]int, len(oldMap)+1) 
  21.  for k, v := range oldMap { 
  22.   newMap[k] = v 
  23.  } 
  24.  newMap[key] = value 
  25.  b.value.Store(newMap) 
  26. } 
  27.  
  28. func BenchmarkAtomicCacheMap_Get(b *testing.B) { 
  29.  atomM := AtomicCacheMap{} 
  30.  atomM.value.Store(testMap) 
  31.  
  32.  b.RunParallel(func(pb *testing.PB) { 
  33.   for pb.Next() { 
  34.    atomM.Get(0) 
  35.   } 
  36.  }) 
  37. } 
  38.  
  39. func BenchmarkAtomicCacheMap_Set(b *testing.B) { 
  40.  atomM := AtomicCacheMap{} 
  41.  atomM.value.Store(testMap) 
  42.  
  43.  var i = 0 
  44.  b.RunParallel(func(pb *testing.PB) { 
  45.   for pb.Next() { 
  46.    atomM.Set(i, i) 
  47.    i++ 
  48.   } 
  49.  }) 
  50. } 
  51.  
  52. /************/ 
  53.  
  54. type MutexCacheMap struct { 
  55.  mutex sync.RWMutex 
  56.  value map[int]int 
  57. } 
  58.  
  59. func (mm *MutexCacheMap) Get(key int) int { 
  60.  mm.mutex.RLock() 
  61.  defer mm.mutex.RUnlock() 
  62.  return mm.value[key] 
  63. } 
  64.  
  65. func (mm *MutexCacheMap) Set(key, value int) { 
  66.  mm.mutex.Lock() 
  67.  defer mm.mutex.Unlock() 
  68.  mm.value[key] = value 
  69. } 
  70.  
  71. func BenchmarkMutexCacheMap_Get(b *testing.B) { 
  72.  mb := MutexCacheMap{value: testMap} 
  73.  
  74.  b.RunParallel(func(pb *testing.PB) { 
  75.   for pb.Next() { 
  76.    mb.Get(0) 
  77.   } 
  78.  }) 
  79. } 
  80.  
  81. func BenchmarkMutexCacheMap_Set(b *testing.B) { 
  82.  mb := MutexCacheMap{value: testMap} 
  83.  
  84.  var i = 0 
  85.  b.RunParallel(func(pb *testing.PB) { 
  86.   for pb.Next() { 
  87.    mb.Set(i, i) 
  88.    i++ 
  89.   } 
  90.  }) 
  91. } 

結(jié)果：

  1. cpu: Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz 
  2. BenchmarkAtomicCacheMap_Get 
  3. BenchmarkAtomicCacheMap_Get-8    301664540           4.194 ns/op 
  4. BenchmarkAtomicCacheMap_Set 
  5. BenchmarkAtomicCacheMap_Set-8       87637            95889 ns/op 
  6. BenchmarkMutexCacheMap_Get 
  7. BenchmarkMutexCacheMap_Get-8     20000959            54.63 ns/op 
  8. BenchmarkMutexCacheMap_Set 
  9. BenchmarkMutexCacheMap_Set-8      5012434            267.2 ns/op 

哎呀，這種表現(xiàn)是痛苦的。這意味著，當(dāng)必須復(fù)制大型結(jié)構(gòu)時(shí)，atomic 的性能非常差。不僅如此，此代碼還包含競(jìng)態(tài)條件。就像本文開(kāi)頭的切片案例一樣，原子緩存示例具有競(jìng)態(tài)條件，其中可能會(huì)在復(fù)制 map 和存儲(chǔ) map 的時(shí)間之間添加新的緩存條目，在這種情況下，新條目將丟失。在這種情況下，該 -race 標(biāo)志不會(huì)檢測(cè)到任何數(shù)據(jù)競(jìng)爭(zhēng)，因?yàn)闆](méi)有對(duì)同一 map 的并發(fā)訪(fǎng)問(wèn)。

07 注意事項(xiàng)

Go 的文檔[2]警告了 atomic 包的潛在誤用：

這些函數(shù)需要非常小心才能正確使用。除了特殊的低級(jí)應(yīng)用程序，同步最好使用通道或 sync 包的工具來(lái)完成。通過(guò)通信共享內(nèi)存;不要通過(guò)共享內(nèi)存進(jìn)行通信。

開(kāi)始使用 atomic 包時(shí)，你可能會(huì)遇到的第一個(gè)問(wèn)題是：

  1. panic: sync/atomic: store of inconsistently typed value into Value 

使用 atomic.Store，確保每次調(diào)用方法時(shí)都存儲(chǔ)完全相同的類(lèi)型很重要。這聽(tīng)起來(lái)很容易，但通常并不像聽(tīng)起來(lái)那么簡(jiǎn)單：

  1. package main 
  2.  
  3. import ( 
  4.  "fmt" 
  5.  "sync/atomic" 
  6. ) 
  7.  
  8. //Our own custom error type which implements the error interface 
  9. type CustomError struct { 
  10.  Code    int 
  11.  Message string 
  12. } 
  13.  
  14. func (e CustomError) Error() string { 
  15.  return fmt.Sprintf("%d: %s", e.Code, e.Message) 
  16. } 
  17.  
  18. func InternalServerError(msg string) error { 
  19.  return CustomError{Code: 500, Message: msg} 
  20. } 
  21.  
  22. func main() { 
  23.  var ( 
  24.   err1 error = fmt.Errorf("error happened") 
  25.   err2 error = InternalServerError("another error happened") 
  26.  ) 
  27.  
  28.  errVal := atomic.Value{} 
  29.  errVal.Store(err1) 
  30.  errVal.Store(err2) //panics here 
  31. } 

兩個(gè)值都是 error 類(lèi)型是不夠的，因?yàn)樗鼈冎皇菍?shí)現(xiàn)了錯(cuò)誤接口。它們的具體類(lèi)型仍然不同，因此 atomic 不喜歡它。

08 總結(jié)

競(jìng)態(tài)條件很糟糕，應(yīng)該保護(hù)對(duì)共享資源的訪(fǎng)問(wèn)?；コ怏w很酷，但由于鎖爭(zhēng)用而趨于緩慢。對(duì)于某些讀取-復(fù)制-更新模式有意義的情況(這往往是動(dòng)態(tài)配置之類(lèi)的東西，例如特性標(biāo)志、日志級(jí)別或 map 或結(jié)構(gòu)體，一次填充例如通過(guò) JSON 解析等)，尤其是當(dāng)讀取次數(shù)比寫(xiě)入次數(shù)多時(shí)。atomic 通常不應(yīng)用于其他用例(例如，隨時(shí)間增長(zhǎng)的變量，如緩存)，并且該特性的使用需要非常小心。

可能最重要的方法是將鎖保持在最低限度，如果你在在考慮原子等替代方案，請(qǐng)務(wù)必在投入生產(chǎn)之前對(duì)其進(jìn)行廣泛的測(cè)試和試驗(yàn)。

原文鏈接：https://www.sixt.tech/golangs-atomic

參考資料

[1]讀取-復(fù)制-更新: https://en.wikipedia.org/wiki/Read-copy-update

[2]文檔: https://pkg.go.dev/sync/atomic

本文轉(zhuǎn)載自微信公眾號(hào)「幽鬼」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系幽鬼公眾號(hào)。

 

責(zé)任編輯：武曉燕 來(lái)源： 幽鬼
Gosyncatomic
相關(guān)推薦

2016-09-27 21:25:08

Go語(yǔ)言Ken Thompso

2021-04-09 09:55:55

DockerGoLinux

2022-06-07 08:39:35

RPCHTTP

2024-07-11 10:41:07

HTTPSHTTP文本傳輸協(xié)議

2019-08-05 14:23:43

DockerKubernetes容器

2020-11-25 09:36:17

HTTPRPC遠(yuǎn)程

2021-11-12 07:21:51

Go線(xiàn)程安全

2023-01-12 09:01:01

MongoDBMySQL

2023-12-11 12:03:14

Python工具元組

2025-10-16 03:00:00

HTTPgRPCAPI

2023-09-12 14:02:30

數(shù)組vector

2025-08-18 02:22:00

2017-01-18 09:42:11

Go

2020-04-07 16:12:56

Go編程語(yǔ)言開(kāi)發(fā)

2020-02-27 21:03:30

調(diào)度器架構(gòu)效率

2021-10-12 18:48:07

HTTP 協(xié)議Websocket網(wǎng)絡(luò)通信

2022-09-13 08:44:02

IP網(wǎng)絡(luò)MAC地址

2021-12-20 10:30:33

forforEach前端

2022-01-12 20:04:09

網(wǎng)絡(luò)故障斷網(wǎng)事件網(wǎng)絡(luò)安全

2024-04-16 08:26:18

IP地址MAC地址
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)