This is a creation in Article, where the information may have evolved or changed.
When using Java it is easy to get the name of the thread, such as "Thread.CurrentThread (). GetName", so that you can do some monitoring operations or set some thread-related data. When it turned to Golang development, it found that the go language did not provide an operation to get the current Goroutine ID. This is Golang developers deliberately, to avoid developers abusing Goroutine ID implementation Goroutine Local storage (Java-like "thread-local" storage), because Goroutine Local Storage It is difficult to do garbage collection. So despite the previous exposure to the corresponding method, it has now been hidden.
Please don ' t use goroutine local storage. It ' s highly discouraged. In fact, IIRC, we used-expose Goid, but it's hidden since we don ' t want people to does this.
Potential problems include:
- when Goroutine goes away, its goroutine local storage won ' t is GCed. (You can get goid for the current goroutine, but can ' t get a list of all running Goroutines)
- What if handler spawns Goroutine itself? The new goroutine suddenly loses access to your goroutine local storage. You can guarantee this your own code won ' t spawn other goroutines,
If you can do sure the standard LIBR ary or any 3rd party code won ' t does that.
Thread Local storage is invented to help reuse bad/legacy code that assumes global state, Go doesn ' t has legacy Code like this, and you really should design your code so the state was passed explicitly and not as global (e.g. resort To Goroutine Local storage)
Of course, this hidden practice of go is still controversial, a bit unworthy. The Goroutine ID is a good monitoring information when debugging log. This article describes two ways to get Goroutine IDs.
The current Goroutine ID can be obtained in the pure Go language. The code looks like this:
12345678910111213141516171819202122232425262728293031323334 |
PackageMainImport("FMT""Runtime""StrConv""Strings""Sync")funcGoID ()int{varBuf[ +]byteN: = runtime. Stack (buf[:],false) IDfield: = Strings. Fields (strings. Trimprefix (string(Buf[:n]),"Goroutine"))[0]id, err: = StrConv. Atoi (IDfield)ifErr! =Nil{Panic(FMT. Sprintf ("Cannot get Goroutine ID:%v", err))}returnIdfuncMain () {FMT. Println ("Main", GoID ())varWG Sync. Waitgroup forI: =0; I <Ten; i++ {i: = IWG. Add(1)Go func() {deferWg. Done () fmt. Println (i, GoID ())} ()}wg. Wait ()} |
go run main.go
Output:
1234567891011 |
main 1 9 14 0 5 1 Span class= "number" >6 2 7 5 10 6 11 3 8 7 12 4 9 8 13 |
It leverages runtime.Stack
the stack information. runtime.Stack(buf []byte, all bool) int
writes the current stack information to a slice, and the first behavior of the stack goroutine #### […
, which ####
is the current Gororutine ID, is implemented by this gimmick GoID
.
However, it is important to note that getting stack information can affect performance, so it is recommended that you use it when you debug.
Resources
- Https://groups.google.com/forum/#!topic/golang-nuts/Nt0hVV_nqHE
- Http://wendal.net/2013/0205.html
- http://blog.sgmansfield.com/2015/12/goroutine-ids/
- Http://dave.cheney.net/2013/09/07/how-to-include-c-code-in-your-go-package
- http://golanghome.com/post/566
- Https://github.com/t-yuki/goid
- Https://github.com/petermattis/goid.git
- Https://github.com/huandu/goroutine