http://blog.golang.org/go-and-google-app-engine“此外，盡管存在 goroutine 和通道，但當(dāng) Go 應(yīng)用程序在 App Engine 上運(yùn)行時(shí)，在給定實(shí)例中僅運(yùn)行一個(gè)線程。也就是說，所有 goroutine 都運(yùn)行在單個(gè)操作系統(tǒng)線程中，因此沒有 CPU 并行性可用于給定客戶請(qǐng)求。我們預(yù)計(jì)此限制將在某個(gè)時(shí)候取消”那是在 2011 年 5 月。它仍然是真的嗎？我有一個(gè)應(yīng)用程序，它只利用 Golang 的速度；獲取一些輸入數(shù)據(jù)，對(duì)其執(zhí)行內(nèi)存計(jì)算，返回結(jié)果。永遠(yuǎn)不要接觸數(shù)據(jù)存儲(chǔ)區(qū)或任何其他 App Engine API。我需要應(yīng)用程序來執(zhí)行許多計(jì)算，理想情況下具有某種程度的并行化。因?yàn)槲沂且粋€(gè) Golang 菜鳥，所以我只是在沒有考慮線程安全的情況下編寫了算法。當(dāng)我一次發(fā)送一個(gè)請(qǐng)求時(shí)，這很有效，但是當(dāng)我嘗試并行發(fā)送多個(gè)計(jì)算時(shí)，所有結(jié)果都是錯(cuò)誤的。我懷疑，但不知道 100%，線程安全是問題所在，尤其是因?yàn)樗惴ㄊ褂玫貓D，而地圖不是線程安全的http://golang.org/doc/faq#atomic_maps所以。如何使我的算法線程安全并獲得某種程度的并行性。第一個(gè)想法是使用通道，這似乎是線程安全的：是否可以將 Go 的緩沖通道用作線程安全隊(duì)列？但是后來我發(fā)現(xiàn)頂部的鏈接表明頻道可能不可用。所以..如果它們不可用，也許我需要為計(jì)算設(shè)置一個(gè)任務(wù)隊(duì)列，它一次只能執(zhí)行一個(gè)計(jì)算。有人可以啟發(fā)我了解在 Golang App Engine 上實(shí)現(xiàn)一定程度線程安全并行化的最佳模式嗎？謝謝。