日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時(shí)間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
在Go語言中，如何正確的使用并發(fā)

Glyph Lefkowitz最近寫了一篇啟蒙文章，其中他詳細(xì)的說明了一些關(guān)于開發(fā)高并發(fā)軟件的挑戰(zhàn)，如果你開發(fā)軟件但是沒有閱讀這篇問題，那么我建議你閱讀一篇。這是一篇非常好的文章，現(xiàn)代軟件工程應(yīng)該擁有的豐富智慧。

創(chuàng)新互聯(lián)公司主要從事做網(wǎng)站、成都網(wǎng)站制作、網(wǎng)頁設(shè)計(jì)、企業(yè)做網(wǎng)站、公司建網(wǎng)站等業(yè)務(wù)。立足成都服務(wù)磐石,十載網(wǎng)站建設(shè)經(jīng)驗(yàn),價(jià)格優(yōu)惠、服務(wù)專業(yè),歡迎來電咨詢建站服務(wù):028-86922220

從多個(gè)花絮中提取，但是如果我斗膽提出主要觀點(diǎn)的總結(jié)，其內(nèi)容就是：搶占式多任務(wù)和一般共享狀態(tài)結(jié)合導(dǎo)致軟件開發(fā)過程不可管理的復(fù)雜性， 開發(fā)人員可能更喜歡保持自己的一些理智以此避免這種不可管理的復(fù)雜性。搶占式調(diào)度對于哪些真正的并行任務(wù)是好的，但是當(dāng)可變狀態(tài)通過多并發(fā)線程共享時(shí)，明確的多任務(wù)合作更招人喜歡 。

盡管合作多任務(wù)，你的代碼仍有可能是復(fù)雜的，它只是有機(jī)會保持可管理下一定的復(fù)雜性。當(dāng)控制轉(zhuǎn)移是明確一個(gè)代碼閱讀者至少有一些可見的跡象表明事情可能脫離正軌。沒有明確標(biāo)記每個(gè)新階段是潛在的地雷：“如果這個(gè)操作不是原子操作，最后出現(xiàn)什么情況？”那么在每個(gè)命令之間的空間變成無盡的空間黑洞，可怕的Heisenbugs出現(xiàn)

在過去的一年多，盡管在Heka上的工作（一個(gè)高性能數(shù)據(jù)、日志和指標(biāo)處理引擎）已大多數(shù)使用GO語言開發(fā)。Go的亮點(diǎn)之一就是語言本身有一些非常有用的并發(fā)原語。但是Go的并發(fā)性能怎么樣，需要通過支持本地推理的鼓勵(lì)代碼鏡頭觀察。

并非事實(shí)都是好的。所有的Goroutine訪問相同的共享內(nèi)存空間，狀態(tài)默認(rèn)可變，但是Go的調(diào)度程序不保證在上下文選擇過程中的準(zhǔn)確性。在單核設(shè)置中，Go的運(yùn)行時(shí)間進(jìn)入“隱式協(xié)同工作”一類， 在Glyph中經(jīng)常提到的異步程序模型列表選擇4。 當(dāng)Goroutine能夠在多核系統(tǒng)中并行運(yùn)行，世事難料。

Go不可能保護(hù)你，但是并不意味著你不能采取措施保護(hù)自己。在寫代碼過程中通過使用一些Go提供的原語，可最小化相關(guān)的搶占式調(diào)度產(chǎn)生的異常行為。請看下面Glyph示例“賬號轉(zhuǎn)換”代碼段中Go接口（忽略哪些不易于最終存儲定點(diǎn)小數(shù)的浮點(diǎn)數(shù)）

 
 
    
  
  
  1. func Transfer(amount float64, payer, payee *Account, 
    2. 
  
  
  2.     server SomeServerType) error { 
    3. 
  
  
  3.  
    4. 
  
  
  4.     if payer.Balance() < amount { 
    5. 
  
  
  5.         return errors.New("Insufficient funds") 
    6. 
  
  
  6.     } 
    7. 
  
  
  7.     log.Printf("%s has sufficient funds", payer) 
    8. 
  
  
  8.     payee.Deposit(amount) 
    9. 
  
  
  9.     log.Printf("%s received payment", payee) 
    10. 
  
  
  10.     payer.Withdraw(amount) 
    11. 
  
  
  11.     log.Printf("%s made payment", payer) 
    12. 
  
  
  12.     server.UpdateBalances(payer, payee) // Assume this is magic and always works. 
    13. 
  
  
  13.     return nil 
    14. 
  
  
  14. } 
    15.

這明顯的是不安全的，如果從多個(gè)goroutine中調(diào)用的話，因?yàn)樗鼈兛赡懿l(fā)的從存款調(diào)度中得到相同的結(jié)果，然后一起請求更多的已取消調(diào)用的存款變量。最好是代碼中危險(xiǎn)部分不會被多goroutine執(zhí)行。在此一種方式實(shí)現(xiàn)了該功能：

 
 
    
  
  
  1. type transfer struct { 
    2. 
  
  
  2.     payer *Account 
    3. 
  
  
  3.     payee *Account 
    4. 
  
  
  4.     amount float64 
    5. 
  
  
  5. } 
    6. 
  
  
  6.  
    7. 
  
  
  7. var xferChan = make(chan *transfer) 
    8. 
  
  
  8. var errChan = make(chan error) 
    9. 
  
  
  9. func init() { 
    10. 
  
  
  10.     go transferLoop() 
    11. 
  
  
  11. } 
    12. 
  
  
  12.  
    13. 
  
  
  13. func transferLoop() { 
    14. 
  
  
  14.     for xfer := range xferChan { 
    15. 
  
  
  15.         if xfer.payer.Balance < xfer.amount { 
    16. 
  
  
  16.             errChan <- errors.New("Insufficient funds") 
    17. 
  
  
  17.             continue 
    18. 
  
  
  18.         } 
    19. 
  
  
  19.         log.Printf("%s has sufficient funds", xfer.payer) 
    20. 
  
  
  20.         xfer.payee.Deposit(xfer.amount) 
    21. 
  
  
  21.         log.Printf("%s received payment", xfer.payee) 
    22. 
  
  
  22.         xfer.payer.Withdraw(xfer.amount) 
    23. 
  
  
  23.         log.Printf("%s made payment", xfer.payer) 
    24. 
  
  
  24.         errChan <- nil 
    25. 
  
  
  25.     } 
    26. 
  
  
  26. } 
    27. 
  
  
  27.  
    28. 
  
  
  28. func Transfer(amount float64, payer, payee *Account, 
    29. 
  
  
  29.     server SomeServerType) error { 
    30. 
  
  
  30.  
    31. 
  
  
  31.     xfer := &transfer{ 
    32. 
  
  
  32.         payer: payer, 
    33. 
  
  
  33.         payee: payee, 
    34. 
  
  
  34.         amount: amount, 
    35. 
  
  
  35.     } 
    36. 
  
  
  36.  
    37. 
  
  
  37.     xferChan <- xfer 
    38. 
  
  
  38.     err := <-errChan 
    39. 
  
  
  39.     if err == nil  { 
    40. 
  
  
  40.         server.UpdateBalances(payer, payee) // Still magic. 
    41. 
  
  
  41.     } 
    42. 
  
  
  42.     return err 
    43. 
  
  
  43. } 
    44.

這里有更多代碼，但是我們通過實(shí)現(xiàn)一個(gè)微不足道的事件循環(huán)消除并發(fā)問題。當(dāng)代碼首次執(zhí)行時(shí)，它激活一個(gè)goroutine運(yùn)行循環(huán)。轉(zhuǎn)發(fā)請求為了此目的而傳遞入一個(gè)新創(chuàng)建的通道。結(jié)果經(jīng)由一個(gè)錯(cuò)誤通道返回到循環(huán)外部。因?yàn)橥ǖ啦皇蔷彌_的，它們加鎖，并且通過Transfer函數(shù)無論多個(gè)并發(fā)的轉(zhuǎn)發(fā)請求怎么進(jìn)，它們都將通過單一的運(yùn)行事件循環(huán)被持續(xù)的服務(wù)。

上面的代碼看起來有點(diǎn)別扭，也許吧. 對于這樣一個(gè)簡單的場景一個(gè)互斥鎖（mutex）也許會是一個(gè)更好的選擇，但是我正要嘗試去證明的是可以向一個(gè)go例程應(yīng)用隔離狀態(tài)操作. 即使稍稍有點(diǎn)尷尬，但是對于大多數(shù)需求而言它的表現(xiàn)已經(jīng)足夠好了，并且它工作起來，甚至使用了最簡單的賬號結(jié)構(gòu)實(shí)現(xiàn):

 
 
    
  
  
  1. type Account struct { 
    2. 
  
  
  2.     balance float64 
    3. 
  
  
  3. } 
    4. 
  
  
  4.  
    5. 
  
  
  5. func (a *Account) Balance() float64 { 
    6. 
  
  
  6.     return a.balance 
    7. 
  
  
  7. } 
    8. 
  
  
  8.  
    9. 
  
  
  9. func (a *Account) Deposit(amount float64) { 
    10. 
  
  
  10.     log.Printf("depositing: %f", amount) 
    11. 
  
  
  11.     a.balance += amount 
    12. 
  
  
  12. } 
    13. 
  
  
  13.  
    14. 
  
  
  14. func (a *Account) Withdraw(amount float64) { 
    15. 
  
  
  15.     log.Printf("withdrawing: %f", amount) 
    16. 
  
  
  16.     a.balance -= amount 
    17. 
  
  
  17. } 
    18.

不過如此笨拙的賬戶實(shí)現(xiàn)看起來會有點(diǎn)天真. 通過不讓任何大于當(dāng)前平衡的撤回操作執(zhí)行，從而讓賬戶結(jié)構(gòu)自身提供一些保護(hù)也許更起作用。那如果我們把撤回函數(shù)變成下面這個(gè)樣子會怎么樣呢?

 
 
    
  
  
  1. func (a *Account) Withdraw(amount float64) { 
    2. 
  
  
  2.     if amount > a.balance { 
    3. 
  
  
  3.         log.Println("Insufficient funds") 
    4. 
  
  
  4.         return 
    5. 
  
  
  5.     } 
    6. 
  
  
  6.     log.Printf("withdrawing: %f", amount) 
    7. 
  
  
  7.     a.balance -= amount 
    8. 
  
  
  8. } 
    9.

不幸的是，這個(gè)代碼患有和我們原來的 Transfer 實(shí)現(xiàn)相同的問題。并發(fā)執(zhí)行或不幸的上下文切換意味著我們可能以負(fù)平衡結(jié)束。幸運(yùn)的是，內(nèi)部的事件循環(huán)理念應(yīng)用在這里同樣很好，甚至更好，因?yàn)槭录h(huán) goroutine 可以與每個(gè)個(gè)人賬戶結(jié)構(gòu)實(shí)例很好的耦合。這里有一個(gè)例子說明這一點(diǎn)：

 
 
    
  
  
  1. type Account struct { 
    2. 
  
  
  2.     balance float64 
    3. 
  
  
  3.     deltaChan chan float64 
    4. 
  
  
  4.     balanceChan chan float64 
    5. 
  
  
  5.     errChan chan error 
    6. 
  
  
  6. } 
    7. 
 
 
 
 
    
  
  
  1. func NewAccount(balance float64) (a *Account) { 
    2. 
  
  
  2.     a = &Account{ 
    3. 
  
  
  3.         balance:     balance, 
    4. 
  
  
  4.         deltaChan:   make(chan float64), 
    5. 
  
  
  5.         balanceChan: make(chan float64), 
    6. 
  
  
  6.         errChan:     make(chan error), 
    7. 
  
  
  7.     } 
    8. 
  
  
  8.     go a.run() 
    9. 
  
  
  9.     return 
    10. 
  
  
  10. } 
    11. 
  
  
  11.  
    12. 
  
  
  12. func (a *Account) Balance() float64 { 
    13. 
  
  
  13.     return <-a.balanceChan 
    14. 
  
  
  14. } 
    15. 
  
  
  15.  
    16. 
  
  
  16. func (a *Account) Deposit(amount float64) error { 
    17. 
  
  
  17.     a.deltaChan <- amount 
    18. 
  
  
  18.     return <-a.errChan 
    19. 
  
  
  19. } 
    20. 
  
  
  20.  
    21. 
  
  
  21. func (a *Account) Withdraw(amount float64) error { 
    22. 
  
  
  22.     a.deltaChan <- -amount 
    23. 
  
  
  23.     return <-a.errChan 
    24. 
  
  
  24. } 
    25. 
  
  
  25.  
    26. 
  
  
  26. func (a *Account) applyDelta(amount float64) error { 
    27. 
  
  
  27.     newBalance := a.balance + amount 
    28. 
  
  
  28.     if newBalance < 0 { 
    29. 
  
  
  29.         return errors.New("Insufficient funds") 
    30. 
  
  
  30.     } 
    31. 
  
  
  31.     a.balance = newBalance 
    32. 
  
  
  32.     return nil 
    33. 
  
  
  33. } 
    34. 
  
  
  34.  
    35. 
  
  
  35. func (a *Account) run() { 
    36. 
  
  
  36.     var delta float64 
    37. 
  
  
  37.     for { 
    38. 
  
  
  38.         select { 
    39. 
  
  
  39.         case delta = <-a.deltaChan: 
    40. 
  
  
  40.             a.errChan <- a.applyDelta(delta) 
    41. 
  
  
  41.         case a.balanceChan <- a.balance: 
    42. 
  
  
  42.             // Do nothing, we've accomplished our goal w/ the channel put. 
    43. 
  
  
  43.         } 
    44. 
  
  
  44.     } 
    45. 
  
  
  45. } 
    46.

這個(gè)API略有不同，Deposit 和 Withdraw 方法現(xiàn)在都返回了錯(cuò)誤。它們并非直接處理它們的請求，而是把賬戶余額的調(diào)整量放入 deltaChan，在 run 方法運(yùn)行時(shí)的事件循環(huán)中訪問 deltaChan。同樣的，Balance 方法通過阻塞不斷地在事件循環(huán)中請求數(shù)據(jù)，直到它通過 balanceChan 接收到一個(gè)值。

須注意的要點(diǎn)是上述的代碼，所有對結(jié)構(gòu)內(nèi)部數(shù)據(jù)值得直接訪問和修改都是有事件循環(huán)觸發(fā)的 *within* 代碼來完成的。如果公共 API 調(diào)用表現(xiàn)良好并且只使用給出的渠道同數(shù)據(jù)進(jìn)行交互的話, 那么不管對公共方法進(jìn)行多少并發(fā)的調(diào)用，我們都知道在任意給定的時(shí)間只會有它們之中的一個(gè)方法得到處理。我們的時(shí)間循環(huán)代碼推理起來更加容易了很多。

該模式的核心是 Heke 的設(shè)計(jì). 當(dāng)Heka啟動(dòng)時(shí)，它會讀取配置文件并且在它自己的go例程中啟動(dòng)每一個(gè)插件. 隨著時(shí)鐘信號、關(guān)閉通知和其它控制信號，數(shù)據(jù)經(jīng)由通道被送入插件中. 這樣就鼓勵(lì)了插件作者使用一種想上述事例那樣的 事件循環(huán)類型的架構(gòu) 來實(shí)現(xiàn)插件的功能.

再次，GO不會保護(hù)你自己. 寫一個(gè)同其內(nèi)部數(shù)據(jù)管理和主題有爭議的條件保持松耦合的Heka插件（或者任何架構(gòu)）是完全可能的。但是有一些需要注意的小地方，還有Go的爭議探測器的自由應(yīng)用程序，你可以編寫的代碼其行為可以預(yù)測，甚至在搶占式調(diào)度的門面代碼中。

英文原文：Sane Concurrency with Go

譯文鏈接：http://www.oschina.net/translate/sane-concurrency-with-go


網(wǎng)頁題目：在Go語言中，如何正確的使用并發(fā)
文章地址：http://www.5511xx.com/article/dhgpdgs.html