Golang sync. Pool Trial instructions and precautions

This is a creation in Article, where the information may have evolved or changed.

Go tip is an experimental branch of the Go language and contains many features that are still being discussed, but are likely to be added to the stable branch. "Go tip is doing" (original address: What's happening in Go tip) The analysis summarizes some important features of the go language in development.

Translated from: What's happening in Go tip (2014-01-10)

It's been 2014 years now, and just after Christmas and New Year's Eve, the Go team has started working on the next release. As a result, the "Go tip What to Do" series has also been re-opened.

As the latest installment in this series, this article will have some minor tweaks. The most important adjustment is to not follow the release cycle of a weekly article. There may be several articles in a week, or none of them. This adjustment is partly due to personal reasons, and partly because of this flexibility to track changes in Go. The result is that each article may be shorter than before, so that you can keep up with the latest development changes.

Another adjustment is that it will overwrite some of the reasons for the formation and discussion of the unchanged code. This is because go 1.3 will have a major change (mainly planning to rewrite the entire compiler with go), and some code needs to be understood early.

We will focus on the type of this article sync.Pool . This type is the first important feature newly added to the Go 1.3 standard library.

What did it do?

• Added a sync.Pool type

• Small changes in the development process

Added a sync.Pool type

Related CL:CL 41860043, cl 43990043, CL 37720047, CL 44080043, CL 44150043, CL 44060044, cl 44050044,CL 44680043, cl 46010043

Projects like the JVM have spent a lot of effort to improve the garbage collection system to ensure that they are dealing with many of the garbage they recycle. On the other hand, Go, generally adopted in the first time to avoid garbage design method, need a less fashionable garbage collection system, to ensure that the memory of the control back to the programmer.

Because of this, some packages in the standard library implement a pool of reused objects to avoid excessive garbage generation. The regexp package maintains a set of state machines in order to ensure concurrent use of the same regular, with a fmt large number of print instances, other packages having their own pools, or this technique can be used.

However, there are two problems with this approach. The most obvious problem is code duplication: Even if important code is mostly the same, all packages need to implement a pool of their own. The more subtle problem is that there is no way to reclaim the space held by the pool. This simple implementation never frees up memory and violates the principle of using garbage-collected languages, resulting in excessive but unnecessary memory usage.

Cache type to the Sync package. This proposal has led to a long series of discussions. Should the Go language provide a type in the standard library, or should this type be used as a private implementation? Should this implementation really release memory? If released, when will it be released? Should this type be called Cache , or should it be called a Pool ?

In this way, the real concern of our pool is just when to reclaim the space occupied by the pool. And there are almost all kinds of possibilities: some are recycled before GC, some are based on the clock or use weak reference pointers after GC. All the suggestions have their drawbacks.

After a lengthy discussion, Russ Cox's final proposed API and recycling strategy is simple: Reclaim pool space when garbage collection is in place. This suggestion reminds us that the Pool purpose of the type is to reuse memory between garbage collection. It should not avoid garbage collection, but rather make garbage collection more efficient.

This proposal was implemented, and after several discussions, it was submitted to the go code base. Of course, this CL is not the end result. First, all the pools are rewritten as sync. Pool . These overrides are traced by CL 43990043,cl 37720047,cl 44080043,cl 44150043,cl 44060044, but does not include CL 44050044. CL 44050044 is concerned with attempting to replace the local release list used in the Encoding/gob package with sync. Pool . Local is a key word. A release list will be as long as the lifetime of a decoder (decoder) until the decoder is destroyed to release the list. Russ Cox replied to this CL and made clear the sync. The purpose of the Pool , and what it cannot be used to do. Until then, Rob Pike submitted and responded to CL 44680043, extending the sync. A Pool type of document that describes its purpose more clearly.

PoolThe design is intended to be a list of releases maintained in global variables, especially global variables that are accessed concurrently by multiple goroutine. Using a Pool release list instead of your own, you can let the program run and reuse a value from the pool in the appropriate scenario. An sync.Pool appropriate approach is to create a pool for the temporary buffers that multiple clients use to share global resources. On the other hand, if releasing a linked list is part of an object and is maintained by this object, and this object is used only by one client, releasing the list after the client's work is done, it Pool is inappropriate to implement this release list.

From the reply (and earlier discussion), joining sync.Pool is still an experiment, and if Pool it does not implement its functionality, it is possible to release Go 1.3 before it is completely removed. The matter was tracked by issue 6984.

Although the exploration of this article is sync.Pool over, the discussion about the pool is not over yet. There is also CL 46010043, which improves the very simple initialization implementation in order to be more suitable for concurrent use. But this CL has not yet passed the audit.

Small changes in the development process

Starting with the cycle of Go 1.3, there are small changes in the development process. These changes will only affect people who are directly involved in the development process, as well as those who follow the latest changes as I do.

A new mailing list is enabled, Golang-coderreviews, and as the default CC object for new CL, replaces the original Golang-dev. The idea is to reduce the noise in the golang-dev so that it can focus on the real discussion.

A new information board is also enabled, allowing the submitter to keep track of the open Issue and CL more easily. Anyone interested in how the Go team works can find useful instructions on this new information board.