Every Go application uses resources, such as files, network connections, HTTP responses, and database query results. But when a resource is left unclosed, it can cause a leak, which drains memory, exhausts system limits, introduces subtle bugs, and eventually brings even the most robust service to failure. Recently, we’ve introduced resource leak analysis in GoLand to address this problem and help you detect unclosed resources before they cause leaks in production.
What is a resource leak?
A resource is any entity that holds an external system handle or state that must be explicitly closed when it’s no longer needed. In Go, such types typically implement the io.Closer interface, which defines a single Close() method for cleaning up underlying resources.
Here are some common implementations of io.Closer:
*os.File:an open file descriptor obtained via functions likeos.Openandos.Create.net.Conn:a network connection (TCP, UDP, etc.) created bynet.Dial,net.Listen.Accept, or similar functions.*http.Response:the response object returned byhttp.Get,http.Post, and similar functions. ItsBodyfield is a resource because it implementsio.ReadCloser.*sql.Rowsand*sql.Conn: database query results and connections.
A resource leak occurs when one of these resources isn’t properly closed after use. In such cases, they continue to occupy memory and other limited system resources such as file descriptors, network sockets, or database connections. Over time, all the open resources may lead to performance degradation, instability, or even application failure.
| The more you know… |
| Can’t Go’s garbage collector handle this? After all, it automatically frees unused memory, so why not resources, too? Go’s garbage collector (GC) is designed specifically to reclaim memory, not to manage external resources like open files or network connections. In some rare cases, it can help. For example, in the standard library, a finalizer can be set to call Close() when a file becomes unreachable. However, this technique is used only as a last resort to protect developers from resource leaks, and you can’t rely on it completely.Garbage collection is non-deterministic. It might occur seconds or minutes later, or not at all, leading to system limits being reached. That’s why the only safe and reliable way to avoid leaks is to explicitly close every file or connection as soon as you’re done with it. |
Tips to prevent resource leaks
What can you do to prevent resource leaks in Go applications? A few consistent habits can help you minimize them.
Tip 1: Use defer to close resources
The defer statement ensures that cleanup happens even if a function returns early or panics. As shown in the example below, we close the created resource right after successfully opening it using defer f.Close(), which is one of the simplest and most effective ways to avoid resource leaks.
f, err := os.Open("data.txt")
if err != nil {
return err
}
defer f.Close()
Since the defer statement executes after the surrounding function’s return, you must handle errors first and only then defer the resource closure. This ensures that you don’t defer operations on invalid or uninitialized resources. Also, avoid placing defer inside loops that create many resources in succession, as this can lead to excessive memory usage.
Tip 2: Test your application under load
Most resource leaks affect your application only under high load, so it’s a good idea to run load and stress tests to see how it behaves. For example, if you’re developing a backend service, you can use load-testing tools like k6, wrk, Vegeta, or others. This testing helps you uncover not only potential resource leaks but also performance bottlenecks and scalability issues before they affect your users.
Tip 3: Use static code analysis tools
Static analysis tools can also help you automatically detect unclosed resources in your code. For instance, golangci-lint includes linters such as bodyclose and sqlclosecheck, which track HTTP response bodies and SQL-related resources to ensure you haven’t forgotten to close them.
Resource leak analysis in GoLand 2025.3 takes this a step further. It scans your code as you write it, verifies that resources are properly closed across all execution paths, and highlights any potential issues in real time. Getting this feedback right in your IDE helps you catch leaks early. Moreover, it works with any type that implements io.Closer, including your custom resource implementations.
When one missing Close() breaks everything
Are resource leaks really that critical? Let’s take a look at two common cases to see how a single missing Close() call can cause serious issues or even break your application over time.
Case 1: Leaking HTTP response bodies
Sending HTTP requests is a common practice in Go, often used to fetch data from external services. Suppose we have a small function that pings an HTTP server:
func ping(url string) (string, error) {
resp, err := http.Get(url)
if err != nil {
return "", err
}
return resp.Status, nil
}
When you write code like this, GoLand warns you about a potential resource leak because of an unclosed response body. But why does it do that? We aren’t even using the body in this example!
Well, let’s try running this code and see what happens. To simulate high-load conditions, we can call our function in a loop like this:
var total int
for {
_, err := ping("http://127.0.0.1:8080/health")
if err != nil {
slog.Error(err.Error())
continue
}
total++
if total%500 == 0 {
slog.Info("500 requests processed", "total", total)
}
time.Sleep(10 * time.Millisecond)
}
At first glance, everything seems fine – the client sends requests and receives responses as expected. However, if you monitor memory usage, you’ll notice that it gradually increases with every request the program sends, which is a clear indicator that something is wrong:
After some time, the client becomes completely unable to send new requests, and the logs start filling up with errors like this:
Why does this happen? When you make an HTTP request in Go, the client sets up a TCP connection and processes the server’s response. The headers are read automatically, but the body remains open until you close it.
Even if you don’t read or use the body, Go’s HTTP client keeps the connection alive, waiting for you to signal that you’re finished with it. If you don’t close it, the TCP connection stays open and cannot be reused. Over time, as more requests are sent, these unclosed connections accumulate, leading to resource leaks and eventually exhausting the available system resources.
That’s exactly what happens in our example. Each iteration of ping() leaves an open response body behind, memory usage grows steadily, and after a while, the client can no longer open new connections, resulting in the can’t assign requested address error.
Let’s correct the mistake and run the code again:
func ping(url string) (string, error) {
resp, err := http.Get(url)
if err != nil {
return "", err
}
defer resp.Body.Close() // Important: close the response body
return resp.Status, nil
}
After applying this fix, the memory footprint remains minimal, and you’ll no longer see the previous errors.
It’s worth mentioning that the code snippet above uses Go’s default http.Client for simplicity, which is generally not recommended in production. By default, it has no request timeout, so a slow or unresponsive server can cause requests to hang indefinitely, potentially leading to stalled goroutines and resource exhaustion. A better practice is to create a custom http.Client with reasonable timeouts to keep your application responsive and resilient under poor network conditions.
Case 2: Forgetting to close SQL rows
Another common and destructive source of leaks in Go applications involves database resources, particularly when using the standard database/sql package. Let’s take a look at a simple function that retrieves user names by country from a database:
func (s *Store) GetUserNamesByCountry(country string) ([]string, error) {
rows, err := s.db.Query(`SELECT name FROM users WHERE country = $1`, country)
if err != nil {
return nil, err
}
var names []string
for rows.Next() {
var name string
if err := rows.Scan(&name); err != nil {
return nil, err
}
names = append(names, name)
}
rows.Close()
return names, rows.Err()
}
Even though we call rows.Close() explicitly, GoLand still warns us about a possible leak. But why?
Let’s say our table looks something like this:
Have you spotted the problem? That’s right, there’s a user without a name. Мore precisely, there is a NULL instead of a string, and the GetUserNamesByCountry function doesn’t handle such cases properly. When rows.Scan tries to assign a NULL to a Go string variable, it returns an error. Issues like this can happen to anyone, and that nameless user probably ended up in our table by mistake. Still, it may seem that such a small issue couldn’t cause any dramatic consequences. After all, that’s exactly why we tried to handle errors properly, right?
Let’s simulate real conditions by calling the function with different input parameters in a loop:
var total int
for {
for _, country := range countries {
_, err := s.GetUserNamesByCountry(country)
if err != nil {
slog.Error(err.Error())
continue
}
total++
if total%100 == 0 {
slog.Info("100 queries processed", "total", total)
}
time.Sleep(10 * time.Millisecond)
}
}
When we launch the program, everything seems fine, and we only get occasional errors as expected:
However, after running and processing SQL queries for some time, our program completely breaks down, and the logs are full of errors like this:
We’ve run out of client connections, and our application is unable to retrieve any data from the database!
The issue is that one of the execution paths in GetUserNamesByCountry leaves the query result unclosed when an error occurs during scanning. If rows is not closed, the corresponding database connection remains in use. Over time, this reduces the number of available connections, and eventually, the connection pool becomes exhausted. That’s exactly what happened in our case.
Surprisingly, just one incorrect row in our table is enough to take down the entire application, simply because we forgot to close the resource properly.
The best way to prevent this mistake is to use defer. As we discussed previously, this should be your preferred way of handling resources whenever possible:
func (s *Store) GetUserNamesByCountry(country string) ([]string, error) {
rows, err := s.db.Query(`SELECT name FROM users WHERE country = $1`, country)
if err != nil {
return nil, err
}
defer rows.Close() // Important: close the rows using 'defer'
var names []string
for rows.Next() {
var name string
if err := rows.Scan(&name); err != nil {
return nil, err
}
names = append(names, name)
}
return names, rows.Err()
}
Making the invisible visible
There are many ways a resource leak can creep into your program, and the examples above are just the tip of the iceberg. Such mistakes are easy to make and hard to trace. Your code compiles, tests pass, and everything appears to work, until your service slows down or starts failing under load. Finding the root cause can be time-consuming, especially in large codebases.
GoLand’s resource leak analysis makes these issues visible right where they start, as you write code. It tracks how resources are used across all execution paths and warns you if something might remain unclosed. This early feedback helps you quickly identify resources in your code and fix potential leaks right away.
The feature is especially helpful for beginners who are still learning the language and might not yet know which resources require explicit cleanup. Experienced developers benefit as well, since it saves time when working with unfamiliar codebases and custom types that implement io.Closer.
In essence, resource leak analysis turns a subtle, hard-to-detect problem into something you can catch instantly, helping you write more reliable and maintainable Go code.
Keeping your Go applications leak-free
Resource leaks are among the most subtle yet destructive bugs in Go applications. They rarely cause immediate crashes, but over time, they can silently degrade performance, create instability, and even bring down production environments.
By using defer consistently, testing under realistic load, and taking advantage of GoLand’s new resource leak analysis, you can catch these issues early and keep your applications stable and reliable. Try out the new feature in the latest GoLand release and let us know what you think!
