How Golang's garbage collection and FINALIZER--TCP connections are automatically closed

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

Recently in making a Golang connection pool. During the test, an interesting phenomenon was found that the connection was not returned to the connection pool, and the connection was automatically closed after a certain period of time. Guess this is not related to the connection pool, and then use a common connection to do the experiment, that is, dial a TCP connection, send the request, and then the program into sleep, after a period of time the connection will be automatically closed.

The process of packet capture analysis, found that the active shutdown connection is the client side, that is, the client side of the active to the server to send fin packets.

Considering that Golang has a garbage collection mechanism, what if the connection is referenced by a program? Will it automatically turn off? Think this should be impossible, then this is not related to garbage collection?!

Minor changes to the program, after the first request is sent, the reference that keep the connection is not released and enters sleep. Observe for a period of time, no matter how long, netstat view that the connection is established state.

So guess it must have something to do with GC.

Sure enough, the StackOverflow found on the Golang GC will also perform a "Finalizer" process, similar to Java. If the object uses Setfinalizer () to set the finalizer function. By default, some objects are automatically set to finalizer:

• Os. File:The file is automatically closed when the object is garbage collected.

• Os. Process:finalization would release any resources associated with the process. On Unix, this is a no-operation. On Windows, it closes the handle associated with the process.

• On Windows, it appears this package net can automatically close a network connection.

The main point is that under Windows, the GC closes the net connection, which is actually the same under the UNIX platform, with the code as proof:

Func (FD *netfd) setaddr (laddr, raddr Addr) {fd.laddr = laddr fd.raddr = raddr runtime. Setfinalizer (FD, (*NETFD). Close)}

This code comes from the Golang source of the Net/fd_unix.go. If the FD is a socket socket, the function is called to set the corresponding finalizer, and the finalizer function is the close () of NETFD.

In the net package, we can also see that Ipconn has a member of the NETFD type inside the structure:

Func newipconn (fd *netfd) *ipconn {return &IPCONN{CONN{FD}}}

Now we understand why connections that are no longer referenced in the program are automatically closed.