Golang Defer: Heap-allocated, Stack-allocated, Open-coded Defer

This is an excerpt of the post; the full post is available here: Golang Defer: From Basic To Trap.

The defer statement is probably one of the first things we find pretty interesting when we start learning Go, right?

But there's a lot more to it that trips up many people, and there're many fascinating aspects that we often don't touch on when using it.

Heap-allocated, Stack-allocated, Open-coded defer

For example, the defer statement actually has 3 types (as of Go 1.22, though that might change later): open-coded defer, heap-allocated defer, and stack-allocated. Each one has different performance and different scenarios where they're best used, which is good to know if you want to optimize performance.

In this discussion, we're going to cover everything from the basics to the more advanced usage, and we'll even dig a bit, just a little bit, into some of the internal details.

What is defer?

Let's take a quick look at defer before we dive too deep.

In Go, defer is a keyword used to delay the execution of a function until the surrounding function finishes.

func main() {
  defer fmt.Println("hello")
  fmt.Println("world")
}

// Output:
// world
// hello

In this snippet, the defer statement schedules fmt.Println("hello") to be executed at the very end of the main function. So, fmt.Println("world") is called immediately, and "world" is printed first. After that, because we used defer, "hello" is printed as the last step before main finishes.

It's just like setting up a task to run later, right before the function exits. This is really useful for cleanup actions, like closing a database connection, freeing up a mutex, or closing a file:

func doSomething() error {
  f, err := os.Open("phuong-secrets.txt")
  if err != nil {
    return err
  }
  defer f.Close()

  // ...
}

The code above is a good example to show how defer works, but it's also a bad way to use defer. We'll get into that in the next section.

"Okay, good, but why not put the f.Close() at the end?"

There are a couple of good reasons for this:

• We put the close action near the open, so it's easier to follow the logic and avoid forgetting to close the file. I don't want to scroll down a function to check if the file is closed or not; it distracts me from the main logic.
• The deferred function is called when the function returns, even if a panic (runtime error) happens.

When a panic happens, the stack is unwound and the deferred functions are executed in a specific order, which we'll cover in the next section.

Defers are stacked

When you use multiple defer statements in a function, they are executed in a 'stack' order, meaning the last deferred function is executed first.

func main() {
  defer fmt.Println(1)
  defer fmt.Println(2)
  defer fmt.Println(3)
}

// Output:
// 3
// 2
// 1

Every time you call a defer statement, you're adding that function to the top of the current goroutine's linked list, like this:

Goroutine defer chain

And when the function returns, it goes through the linked list and executes each one in the order shown in the image above.

But remember, it does not execute all the defer in the linked list of goroutine, it's only run the defer in the returned function, because our defer linked list could contain many defers from many different functions.

func B() {
  defer fmt.Println(1)
  defer fmt.Println(2)
  A()
}

func A() {
  defer fmt.Println(3)
  defer fmt.Println(4)
}

So, only the deferred functions in the current function (or current stack frame) are executed.

Goroutine defer chain

But there's one typical case where all the deferred functions in the current goroutine get traced and executed, and that's when a panic happens.

Defer, Panic and Recover

Besides compile-time errors, we have a bunch of runtime errors: divide by zero (integer only), out of bounds, dereferencing a nil pointer, and so on. These errors cause the application to panic.

Panic is a way to stop the execution of the current goroutine, unwind the stack, and execute the deferred functions in the current goroutine, causing our application to crash.

To handle unexpected errors and prevent the application from crashing, you can use the recover function within a deferred function to regain control of a panicking goroutine.

func main() {
  defer func() {
    if r := recover(); r != nil {
      fmt.Println("Recovered:", r)
    }
  }()

  panic("This is a panic")
}

// Output:
// Recovered: This is a panic

Usually, people put an error in the panic and catch that with recover(..), but it could be anything: a string, an int, etc.

In the example above, inside the deferred function is the only place you can use recover. Let me explain this a bit more.

There are a couple of mistakes we could list here. I’ve seen at least three snippets like this in real code.

The first one is, using recover directly as a deferred function:

func main() {
  defer recover()

  panic("This is a panic")
}

The code above still panics, and this is by design of the Go runtime.

The recover function is meant to catch a panic, but it has to be called within a deferred function to work properly.

Behind the scenes, our call to recover is actually the runtime.gorecover, and it checks that the recover call is happening in the right context, specifically from the correct deferred function that was active when the panic occurred.

"Does that mean we can’t use recover in a function inside a deferred function, like this?"

func myRecover() {
  if r := recover(); r != nil {
    fmt.Println("Recovered:", r)
  }
}

func main() {
  defer func() {
    myRecover()
    // ...
  }()

  panic("This is a panic")
}

Exactly, the code above won’t work as you might expect. That’s because recover isn’t called directly from a deferred function but from a nested function.

Now, another mistake is trying to catch a panic from a different goroutine:

func main() {
  defer func() {
    if r := recover(); r != nil {
      fmt.Println("Recovered:", r)
    }
  }()

  go panic("This is a panic")

  time.Sleep(1 * time.Second) // Wait for the goroutine to finish
}

Makes sense, right? We already know that defer chains belong to a specific goroutine. It would be tough if one goroutine could intervene in another to handle the panic since each goroutine has its own stack.

Unfortunately, the only way out in this case is crashing the application if we don’t handle the panic in that goroutine.

Defer arguments, including receiver are immediately evaluated

I've run into this problem before, where old data got pushed to the analytics system, and it was tough to figure out why.

Here’s what I mean:

func pushAnalytic(a int) {
  fmt.Println(a)
}

func main() {
  a := 10
  defer pushAnalytic(a)

  a = 20
}

What do you think the output will be? It's 10, not 20.

That's because when you use the defer statement, it grabs the values right then. This is called "capture by value." So, the value of a that gets sent to pushAnalytic is set to 10 when the defer is scheduled, even though a changes later.

There are two ways to fix this.

...

Full post is available here: Golang Defer: From Basic To Trap.

The above is the detailed content of Golang Defer: Heap-allocated, Stack-allocated, Open-coded Defer. For more information, please follow other related articles on the PHP Chinese website!