शीर्ष 10 सबसे आम गलतियाँ जो मुझे गो-परियोजनाओं में सामना करना पड़ा है

यह पोस्ट मेरी सबसे आम गलतियों में से एक है जो मुझे गो-प्रोजेक्ट्स में मिली थी। आदेश मायने नहीं रखता।

एनम का अज्ञात मूल्य

आइए एक सरल उदाहरण देखें:

type Status uint32 const ( StatusOpen Status = iota StatusClosed StatusUnknown ) 

यहां हम iota का उपयोग कर एक एन्यूमरेटर बनाते हैं, जो इस स्थिति को जन्म देगा:

 StatusOpen = 0 StatusClosed = 1 StatusUnknown = 2 

अब कल्पना करते हैं कि इस प्रकार की स्थिति JSON अनुरोध का हिस्सा है जिसे पैक / अनपैक्ड किया जाएगा। हम निम्नलिखित संरचना डिजाइन कर सकते हैं:

 type Request struct { ID int `json:"Id"` Timestamp int `json:"Timestamp"` Status Status `json:"Status"` } 

फिर हमें यह क्वेरी परिणाम मिलता है:

 { "Id": 1234, "Timestamp": 1563362390, "Status": 0 } 

सामान्य तौर पर, कुछ भी विशेष नहीं - स्टेटस को स्टेटसपेन में अनपैक किया जाएगा।
अब, एक और उत्तर मिलता है जिसमें स्थिति मान सेट नहीं है:

 { "Id": 1235, "Timestamp": 1563362390 } 

इस स्थिति में, अनुरोध संरचना का स्थिति क्षेत्र शून्य पर प्रारंभ हो जाएगा (uint32 के लिए यह 0 है)। इसलिए, हम फिर से StatusUnogn के बजाय StatusOpen प्राप्त करते हैं।

इस मामले में, एन्यूमरेटर के अज्ञात मूल्य को पहले सेट करना सबसे अच्छा है - अर्थात। 0:

 type Status uint32 const ( StatusUnknown Status = iota StatusOpen StatusClosed ) 

यदि स्थिति JSON अनुरोध का हिस्सा नहीं है, तो यह StatusUnaware में आरंभिक हो जाएगा, जैसा कि हम उम्मीद करते हैं।

बेंच मार्किंग

सही बेंचमार्किंग करना काफी मुश्किल है। बहुत से कारक परिणाम को प्रभावित कर सकते हैं।

एक सामान्य गलती कंपाइलर ऑप्टिमाइजेशन द्वारा छल की जा रही है। आइए देखें तिवह / बिटवेक्टर लाइब्रेरी से एक विशिष्ट उदाहरण:

 func clear(n uint64, i, j uint8) uint64 { return (math.MaxUint64<<j | ((1 << i) - 1)) & n } 

यह फ़ंक्शन दी गई सीमा में बिट्स को साफ करता है। हम इस तरह से प्रदर्शन का परीक्षण कर सकते हैं:

 func BenchmarkWrong(b *testing.B) { for i := 0; i < bN; i++ { clear(1221892080809121, 10, 63) } } 

इस परीक्षण में, संकलक ध्यान देगा कि स्पष्ट किसी अन्य फ़ंक्शन को कॉल नहीं करता है, इसलिए यह बस इसे उसी तरह एम्बेड करता है। एक बार जब यह निर्मित हो जाता है, तो संकलक यह देखेगा कि कोई साइड इफेक्ट नहीं होता है। इस प्रकार, स्पष्ट कॉल बस हटा दी जाएगी, जिससे गलत परिणाम होंगे।

इसका एक परिणाम वैश्विक चर के परिणाम को निर्धारित करना हो सकता है, जैसे कि:

 var result uint64 func BenchmarkCorrect(b *testing.B) { var r uint64 for i := 0; i < bN; i++ { r = clear(1221892080809121, 10, 63) } result = r } 

यहां कंपाइलर को पता नहीं चलेगा कि कॉल साइड इफेक्ट बनाता है या नहीं। इसलिए, बेंचमार्क सटीक होगा।

संकेत! हर जगह संकेत हैं!

किसी वैरिएबल को वैल्यू से पास करने से इस वैरिएबल की कॉपी बन जाएगी पॉइंटर से गुज़रते समय बस एड्रेस को मेमोरी में कॉपी करें।

नतीजतन, एक पॉइंटर पास करना हमेशा तेज होगा, है ना?

यदि आप ऐसा सोचते हैं, तो इस उदाहरण पर एक नज़र डालें। यह 0.3 KB डेटा संरचना के लिए एक बेंचमार्क है जिसे हम पहले पॉइंटर द्वारा, और फिर मूल्य द्वारा प्रसारित और प्राप्त करते हैं। 0.3 KB एक बिट है - सामान्य डेटा संरचनाओं के बारे में जो हम हर दिन उस पर कब्जा करते हैं।

जब मैं इन परीक्षणों को स्थानीय वातावरण में चलाता हूं, तो मूल्य-दर-मूल्य संचरण 4 गुना से अधिक तेज होता है। बहुत अप्रत्याशित, है ना?

इस परिणाम की व्याख्या यह समझने से संबंधित है कि स्मृति प्रबंधन गो में कैसे होता है। मैं इसे विलियम कैनेडी के रूप में शानदार ढंग से नहीं समझा सकता, लेकिन आइए संक्षेप में संक्षेप में बताने का प्रयास करते हैं।

एक चर को ढेर या स्टैक पर रखा जा सकता है:

• स्टैक में इस कार्यक्रम के वर्तमान चर शामिल हैं। जैसे ही फ़ंक्शन वापस आता है, चर स्टैक से पॉपअप होते हैं।
• ढेर में सामान्य चर (वैश्विक चर, आदि) होते हैं।

आइए एक साधारण उदाहरण देखें जहां हम एक मान लौटाते हैं:

 func getFooValue() foo { var result foo // Do something return result } 

यहां परिणाम चर को वर्तमान गोरोइन द्वारा बनाया गया है। यह चर वर्तमान ढेर पर धकेल दिया जाता है। जैसे ही फ़ंक्शन वापस आता है, ग्राहक को इस चर की एक प्रति प्राप्त होगी। वैरिएबल स्वयं स्टैक से पॉप होता है। यह तब भी मेमोरी में मौजूद रहता है जब तक कि दूसरा वेरिएबल ओवरराइट न हो जाए, लेकिन इसे एक्सेस नहीं किया जा सकता।
अब एक ही उदाहरण है, लेकिन एक सूचक के साथ:

 func getFooPointer() *foo { var result foo // Do something return &result } 

परिणाम चर अभी भी वर्तमान गोरोइन द्वारा बनाया गया है, लेकिन ग्राहक को एक सूचक (चर के पते की एक प्रति) प्राप्त होगा। यदि परिणाम चर स्टैक से पॉप किया गया था, तो इस फ़ंक्शन का क्लाइंट इसे एक्सेस नहीं कर पाएगा।

इस परिदृश्य में, गो संकलक परिणाम चर को आउटपुट करेगा जहां चर साझा किए जा सकते हैं, अर्थात। एक गुच्छा में।

पासिंग पॉइंटर्स के लिए एक और स्क्रिप्ट:

 func main() { p := &foo{} f(p) } 

चूँकि हम एक ही प्रोग्राम में f कहते हैं, इसलिए वेरिएबल p को heaped करने की आवश्यकता नहीं है। यह बस स्टैक पर धकेल दिया जाता है, और एक सबफ़ंक्शन इसे एक्सेस कर सकता है।

उदाहरण के लिए, इस तरह से एक टुकड़ा io.Reader की पढ़ें विधि में प्राप्त किया जाता है। एक स्लाइस (जो एक पॉइंटर है) को वापस करना एक ढेर में रखता है।

ढेर इतनी जल्दी क्यों है? इसके दो कारण हैं:

• स्टैक पर कचरा कलेक्टर का उपयोग करने की आवश्यकता नहीं है। जैसा कि हमने पहले ही कहा था, एक वैरिएबल को केवल बनाए जाने के बाद धकेला जाता है, और फिर फ़ंक्शन के वापस आने पर स्टैक से पॉप किया जाता है। अप्रयुक्त चर, आदि को वापस करने के लिए एक जटिल प्रक्रिया को उत्तेजित करने की आवश्यकता नहीं है।
• स्टैक एक गोरोइन का है, इसलिए चर के भंडारण को सिंक्रनाइज़ करने की आवश्यकता नहीं है, क्योंकि यह ढेर पर भंडारण के साथ होता है, जिससे प्रदर्शन में वृद्धि भी होती है।

निष्कर्ष में, जब हम एक फ़ंक्शन बनाते हैं, तो हमारी डिफ़ॉल्ट कार्रवाई बिंदुओं के बजाय मूल्यों का उपयोग करना चाहिए। यदि हम एक चर साझा करना चाहते हैं तो एक सूचक का उपयोग किया जाना चाहिए।

इसके अलावा, यदि हम प्रदर्शन के मुद्दों से पीड़ित हैं, तो संभावित स्थितियों में से एक में मदद करने के लिए संभावित अनुकूलन में से एक की जांच हो सकती है? कंपाइलर एक चर का उत्पादन करता है या नहीं यह निम्न कमांड के साथ पता लगाया जा सकता है:

 go build -gcflags "-m -m" 

।
लेकिन, फिर से, हमारे अधिकांश दैनिक कार्यों के लिए, मूल्यों का उपयोग करना सबसे अच्छा है।

/ स्विच या के लिए / चयन के लिए गर्भपात

निम्नलिखित उदाहरण में क्या होता है यदि एफ रिटर्न सही है?

 for { switch f() { case true: break case false: // Do something } } 

हम ब्रेक कहते हैं। केवल यह ब्रेक स्विच को तोड़ता है, लूप के लिए नहीं।

यहाँ एक ही मुद्दा:

 for { select { case <-ch: // Do something case <-ctx.Done(): break } } 

ब्रेक एक चयनित कथन के साथ जुड़ा हुआ है, लूप के लिए नहीं।

एक लेबल का उपयोग करने के लिए / स्विच या / चयन के लिए बाधित करने के लिए एक संभव समाधान है:

 loop: for { select { case <-ch: // Do something case <-ctx.Done(): break loop } } 

हैंडलिंग में त्रुटि

गो अभी भी युवा है, विशेष रूप से एरर हैंडलिंग के क्षेत्र में। इस कमी को दूर करना Go 2 में सबसे प्रतीक्षित नवाचारों में से एक है।

वर्तमान मानक पुस्तकालय (1.13 से पहले) त्रुटियों के निर्माण के लिए केवल कार्य प्रदान करता है। इसलिए, यह pkg / त्रुटियों के पैकेज पर एक नज़र रखना दिलचस्प होगा।

यह पुस्तकालय एक नियम का पालन करने का एक अच्छा तरीका है जो हमेशा सम्मानित नहीं होता है:

त्रुटि को केवल एक बार संसाधित किया जाना चाहिए। त्रुटि लॉगिंग त्रुटि हैंडलिंग है

। इस प्रकार, त्रुटि को लॉग या अधिक उछाला जाना चाहिए।

वर्तमान मानक पुस्तकालय में, इस सिद्धांत का पालन करना मुश्किल है, क्योंकि हम त्रुटि के संदर्भ जोड़ना चाहते हैं और किसी प्रकार का पदानुक्रम हो सकता है।

आइए एक उदाहरण देखें जिसमें REST एक डेटाबेस त्रुटि के लिए अग्रणी है:

 unable to server HTTP POST request for customer 1234 |_ unable to insert customer contract abcd |_ unable to commit transaction 

यदि हम pkg / त्रुटियों का उपयोग करते हैं, तो हम निम्नलिखित कर सकते हैं:

 func postHandler(customer Customer) Status { err := insert(customer.Contract) if err != nil { log.WithError(err).Errorf("unable to server HTTP POST request for customer %s", customer.ID) return Status{ok: false} } return Status{ok: true} } func insert(contract Contract) error { err := dbQuery(contract) if err != nil { return errors.Wrapf(err, "unable to insert customer contract %s", contract.ID) } return nil } func dbQuery(contract Contract) error { // Do something then fail return errors.New("unable to commit transaction") } 

प्रारंभिक त्रुटि (यदि यह बाहरी लाइब्रेरी द्वारा वापस नहीं की जाती है) त्रुटियों का उपयोग करके बनाई जा सकती है। मध्य परत, इस त्रुटि को सम्मिलित करता है, इसमें अधिक संदर्भ जोड़ता है। फिर अभिभावक उसे लॉग करते हैं। इस प्रकार, प्रत्येक स्तर या तो त्रुटि देता है या प्रक्रिया करता है।

हम त्रुटि का कारण भी खोजना चाहते हैं, उदाहरण के लिए, कॉल बैक करना। मान लीजिए कि हमारे पास एक बाहरी लाइब्रेरी से एक db पैकेज है जिसकी डेटाबेस तक पहुंच है। यह लाइब्रेरी db.DBError नामक अस्थायी त्रुटि लौटा सकती है। यह निर्धारित करने के लिए कि क्या हमें पुनः प्रयास करने की आवश्यकता है, हमें त्रुटि का कारण स्थापित करना चाहिए:

 func postHandler(customer Customer) Status { err := insert(customer.Contract) if err != nil { switch errors.Cause(err).(type) { default: log.WithError(err).Errorf("unable to server HTTP POST request for customer %s", customer.ID) return Status{ok: false} case *db.DBError: return retry(customer) } } return Status{ok: true} } func insert(contract Contract) error { err := db.dbQuery(contract) if err != nil { return errors.Wrapf(err, "unable to insert customer contract %s", contract.ID) } return nil } 

यह त्रुटियों का उपयोग करके किया जाता है। रोकें, जो कि pkg / त्रुटियों में भी शामिल है:

मेरे द्वारा सामना की जाने वाली सामान्य त्रुटियों में से एक आंशिक रूप से केवल pkg / त्रुटियों का उपयोग था। एक त्रुटि जाँच, उदाहरण के लिए, निम्नानुसार किया गया था:

 switch err.(type) { default: log.WithError(err).Errorf("unable to server HTTP POST request for customer %s", customer.ID) return Status{ok: false} case *db.DBError: return retry(customer) } 

इस उदाहरण में, अगर db.DBError को लपेटा जाता है, तो यह कभी भी दूसरा कॉल नहीं करेगा।

स्लाइस इनिशियलाइज़ेशन

कभी-कभी हम जानते हैं कि स्लाइस की अंतिम लंबाई क्या होगी। उदाहरण के लिए, मान लें कि हम फू स्लाइस को बार स्लाइस में बदलना चाहते हैं, जिसका मतलब है कि इन दो स्लाइस की लंबाई समान होगी।

मैं अक्सर स्लाइस भर में इस तरह से आते हैं:

 var bars []Bar bars := make([]Bar, 0) 

स्लाइस एक जादुई संरचना नहीं है। हुड के तहत, वह आकार बढ़ाने के लिए एक रणनीति लागू करता है यदि कोई अधिक खाली स्थान नहीं है। इस मामले में, एक नई सरणी स्वचालित रूप से (एक बड़ी क्षमता के साथ) बनाई जाती है, और सभी तत्वों को इसकी प्रतिलिपि बनाई जाती है।

अब कल्पना करें कि हमें कई बार आकार बढ़ाने के इस ऑपरेशन को दोहराने की आवश्यकता है, क्योंकि हमारे [] फू में हजारों तत्व हैं। सम्मिलन एल्गोरिथ्म की जटिलता ओ (1) रहेगी, लेकिन व्यवहार में यह प्रदर्शन को प्रभावित करेगा।

इसलिए, यदि हम अंतिम लंबाई जानते हैं, तो हम भी कर सकते हैं:

• इसे पूर्वनिर्धारित लंबाई के साथ प्रारंभ करें:

 func convert(foos []Foo) []Bar { bars := make([]Bar, len(foos)) for i, foo := range foos { bars[i] = fooToBar(foo) } return bars } 

• या इसे 0 की लंबाई और एक पूर्व निर्धारित क्षमता के साथ आरंभ करें:

 func convert(foos []Foo) []Bar { bars := make([]Bar, 0, len(foos)) for _, foo := range foos { bars = append(bars, fooToBar(foo)) } return bars } 

सबसे अच्छा विकल्प क्या है? पहला थोड़ा तेज है। हालांकि, आप उत्तरार्द्ध को पसंद कर सकते हैं क्योंकि यह अधिक सुसंगत है: चाहे हम प्रारंभिक आकार को जानते हों, स्लाइस के अंत में एक तत्व जोड़ना एपेंड का उपयोग करके किया जाता है।

प्रसंग प्रबंधन

संदर्भ। कॉन्टेक्स्ट अक्सर डेवलपर्स द्वारा गलत समझा जाता है। आधिकारिक दस्तावेज के अनुसार:

संदर्भ एपीआई की सीमाओं के पार समय-सीमा, रद्द संकेत और अन्य मूल्यों को वहन करता है।
यह विवरण काफी सामान्य है, इसलिए यह प्रोग्रामर को भ्रमित कर सकता है कि इसे सही तरीके से कैसे उपयोग किया जाए।

आइए इसे जानने की कोशिश करते हैं। संदर्भ ले जा सकते हैं:

• समय सीमा - का अर्थ है या तो अवधि (उदाहरण के लिए, 250 एमएस) या तारीख-समय (उदाहरण के लिए, 2019-01-08 01:00:00), जिसके अनुसार हमारा मानना ​​है कि यदि यह पहुंच गया है, तो वर्तमान कार्रवाई को रद्द कर दिया जाना चाहिए (I / O अनुरोध ), चैनल इनपुट के लिए प्रतीक्षा कर रहा है, आदि)।
• संकेत रद्द करें (मूल रूप से <-चान संरचना {})। यहाँ व्यवहार समान है। जैसे ही हमें कोई संकेत मिलता है, हमें वर्तमान कार्य रोकना चाहिए। उदाहरण के लिए, मान लें कि हमें दो अनुरोध मिले हैं। एक डेटा डालने के लिए, और दूसरा पहला अनुरोध रद्द करने के लिए (क्योंकि यह अब प्रासंगिक नहीं है, उदाहरण के लिए)। इसे पहले कॉल में रद्द किए गए संदर्भ का उपयोग करके प्राप्त किया जा सकता है, जिसे हम दूसरा अनुरोध प्राप्त करते ही रद्द कर देंगे।
• कुंजी / मूल्य सूची (दोनों इंटरफ़ेस पर आधारित {} प्रकार)।

दो और बिंदु। सबसे पहले, संदर्भ रचना योग्य है। इसलिए, हमारे पास एक संदर्भ हो सकता है जो उदाहरण के लिए समय सीमा और कुंजी / मूल्य सूची को वहन करता है। इसके अलावा, कई गोरोनाइट एक ही संदर्भ साझा कर सकते हैं, इसलिए एक रद्द संकेत संभावित रूप से कई नौकरियों को रोक सकता है।

हमारे विषय पर लौटते हुए, यहाँ एक गलती है जो मुझे मिली।

गो एप्लिकेशन urfave / cli पर आधारित था (यदि आप नहीं जानते हैं, यह गो में कमांड-लाइन एप्लिकेशन बनाने के लिए एक अच्छा पुस्तकालय है)। एक बार लॉन्च होने के बाद, डेवलपर को एक तरह का एप्लिकेशन संदर्भ विरासत में मिलता है। इसका मतलब यह है कि जब आवेदन बंद हो जाता है, तो पुस्तकालय संदर्भ को रद्द संकेत भेजने के लिए उपयोग करेगा।

मैंने देखा कि इस संदर्भ को सीधे प्रसारित किया गया था, उदाहरण के लिए, जब एक जीआरपीसी समापन बिंदु कहा जाता था। यह वह नहीं है जो हमें चाहिए।

इसके बजाय, हम gRPC लाइब्रेरी को बताना चाहते हैं: उदाहरण के लिए, आवेदन बंद होने पर, या 100 एमएस के बाद अनुरोध को रद्द करें।

इसे प्राप्त करने के लिए, हम बस एक समग्र संदर्भ बना सकते हैं। यदि माता-पिता एप्लिकेशन संदर्भ ( urfave / cli द्वारा निर्मित) का नाम है, तो हम बस यह कर सकते हैं:

 ctx, cancel := context.WithTimeout(parent, 100 * time.Millisecond) response, err := grpcClient.Send(ctx, request) 

संदर्भों को समझना इतना मुश्किल नहीं है, और, मेरी राय में, यह भाषा की सबसे अच्छी विशेषताओं में से एक है।

-Race विकल्प का उपयोग नहीं करना

ग्रेस विकल्प के बिना गो एप्लिकेशन का परीक्षण करना एक बग है जिसका मैं लगातार सामना करता हूं।

जैसा कि इस लेख में लिखा गया है , हालांकि गो को " समानांतर प्रोग्रामिंग को सरल और कम त्रुटि वाला बनाने के लिए डिज़ाइन किया गया था , " हम अभी भी संगामिति मुद्दों से बहुत पीड़ित हैं।

जाहिर है, रेस डिटेक्टर गो किसी भी समस्या के साथ मदद नहीं करेगा। हालांकि, यह एक मूल्यवान उपकरण है, और हमें अपने अनुप्रयोगों का परीक्षण करते समय इसे हमेशा शामिल करना चाहिए।

इनपुट के रूप में फ़ाइल नाम का उपयोग करना

एक और आम गलती एक फ़ंक्शन के लिए फ़ाइल नाम को पास करना है।

मान लीजिए कि हमें किसी फ़ाइल में खाली लाइनों की संख्या की गणना करने के लिए फ़ंक्शन को लागू करने की आवश्यकता है। सबसे प्राकृतिक कार्यान्वयन कुछ इस तरह दिखेगा:

 func count(filename string) (int, error) { file, err := os.Open(filename) if err != nil { return 0, errors.Wrapf(err, "unable to open %s", filename) } defer file.Close() scanner := bufio.NewScanner(file) count := 0 for scanner.Scan() { if scanner.Text() == "" { count++ } } return count, nil } 

फ़ाइल नाम इनपुट के रूप में सेट किया गया है, इसलिए हम इसे खोलते हैं और फिर अपने तर्क को लागू करते हैं, है ना?

अब मान लें कि हम इस फ़ंक्शन को यूनिट परीक्षणों के साथ कवर करना चाहते हैं। हम एक नियमित फ़ाइल, एक खाली फ़ाइल, विभिन्न प्रकार के एन्कोडिंग के साथ एक फ़ाइल आदि के साथ परीक्षण करेंगे, इसे प्रबंधित करना बहुत मुश्किल हो सकता है।

इसके अलावा, यदि हम उसी तर्क को लागू करना चाहते हैं, उदाहरण के लिए, HTTP निकाय के लिए, हमें इसके लिए एक और फ़ंक्शन बनाने की आवश्यकता होगी।

गो दो महान सार के साथ आता है: io.Reader और io.Writer। फ़ाइल नाम पास करने के बजाय, हम बस io.Reader पास कर सकते हैं, जो डेटा स्रोत को अमूर्त करेगा।
क्या यह एक फाइल है? HTTP बॉडी? बाइट बफर? इससे कोई फर्क नहीं पड़ता, क्योंकि हम अभी भी उसी विधि का उपयोग करेंगे।

हमारे मामले में, हम इसे इनपुट लाइन द्वारा पढ़ने के लिए बफर इनपुट भी कर सकते हैं। ऐसा करने के लिए, आप bufio.Reader और इसकी ReadLine विधि का उपयोग कर सकते हैं:

 func count(reader *bufio.Reader) (int, error) { count := 0 for { line, _, err := reader.ReadLine() if err != nil { switch err { default: return 0, errors.Wrapf(err, "unable to read") case io.EOF: return count, nil } } if len(line) == 0 { count++ } } } 

अब फ़ाइल खोलने की जिम्मेदारी काउंट क्लाइंट को दी गई है:

 file, err := os.Open(filename) if err != nil { return errors.Wrapf(err, "unable to open %s", filename) } defer file.Close() count, err := count(bufio.NewReader(file)) 

एक दूसरे कार्यान्वयन में, वास्तविक डेटा स्रोत की परवाह किए बिना एक फ़ंक्शन को बुलाया जा सकता है। इस बीच, यह हमारी इकाई परीक्षण की सुविधा प्रदान करेगा, क्योंकि हम बस लाइन से bufio.Reader बना सकते हैं:

 count, err := count(bufio.NewReader(strings.NewReader("input"))) 

गोराउटाइन्स और चक्र चर

आखिरी आम गलती जो मुझे मिली थी, वह लूप वेरिएबल्स वाले गोरोइन्ट्स का उपयोग करना था।

निम्नलिखित उदाहरण का निष्कर्ष क्या होगा?

 ints := []int{1, 2, 3} for _, i := range ints { go func() { fmt.Printf("%v\n", i) }() } 

1 2 3 बेतरतीब ढंग से? नहीं।

इस उदाहरण में, प्रत्येक गोरआउट एक चर के एक ही उदाहरण का उपयोग करता है, इसलिए यह 3 3 3 (सबसे अधिक संभावना) आउटपुट देगा।

इस समस्या के दो समाधान हैं। पहला वैरिएबल i के क्लोजर (आंतरिक फ़ंक्शन) के मान को पास करना है:

 ints := []int{1, 2, 3} for _, i := range ints { go func(i int) { fmt.Printf("%v\n", i) }(i) } 

दूसरा लूप के भीतर एक और वैरिएबल बनाने के लिए है:

 ints := []int{1, 2, 3} for _, i := range ints { i := i go func() { fmt.Printf("%v\n", i) }() } 

मुझे असाइन करना: = मुझे थोड़ा अजीब लग सकता है, लेकिन यह डिज़ाइन पूरी तरह से वैध है। लूप में होने का मतलब है एक अलग दायरे में होना। इसलिए, i: = i वैरिएबल का एक और उदाहरण i बनाता है। बेशक, हम इसे पठनीयता के लिए एक अलग नाम से पुकार सकते हैं।

यदि आप अन्य सामान्य गलतियों को जानते हैं, तो टिप्पणियों में उनके बारे में लिखने के लिए स्वतंत्र महसूस करें।