Go deferの原理とソースコード分解（推奨）

type _defer struct {
    siz int32 // memory size of parameters and return values
    started boul
    heap boul // distinguishes whether the structure is allocated on the stack or on the pair
    sp uintptr // sp counter value, stack pointer.
    pc uintptr // pc counter value, program counter.
    fn *funcval // address of the function passed in by defer, i.e., the function whose execution is deferred;
    _panic *_panic // panic that is running defer
    link *_defer // link table
}

package main

func doDeferFunc(x int) {
    println(x)
}

func doSomething() int {
    var x = 1
    defer doDeferFunc(x)
    x += 2
    return x
}

func main() {
    x := doSomething()
    println(x)
}

func (s *state) stmt(n *Node) {
 
    case ODEFER:
        d := callDefer
        if n.Esc == EscNever {
            d = callDeferStack
        }
}

func (e *EscState) esc(n *Node, parent *Node) {

    case ODEFER:
        if e.loopdepth == 1 { // top level
            n.Esc = EscNever // force stack allocation of defer record (see ssa.go)
            break
        }
}

package main

func main() {
    for i := 0; i < 10; i++ {
        defer func() {
            _ = i
        }()
    }
}

// The memory structure is already allocated on the stack before entering this function
func deferprocStack(d *_defer) {
    gp := getg()

    // siz and fn are assigned before entering this function
    d.started = false
    // indicates that it is the memory of the stack
    d.heap = false
    // Get the rsp register value of the caller function and assign it to the sp field of the _defer structure
    d.sp = getcallersp()
    // Get the rip register value of the caller function and assign it to the pc field of the _defer structure
    // Based on the principle of function calls, we know that the pc (rip) value of the caller's stack is the next instruction in the deferprocStack
    d.pc = getcallerpc()

    // hook this _defer structure into the goroutine's chain as a node
    *(*uintptr)(unsafe.Pointer(&d._panic)) = 0
    *(*uintptr)(unsafe.Pointer(&d.link)) = uintptr(unsafe.Pointer(gp._defer))
    *(*uintptr)(unsafe.Pointer(&gp._defer)) = uintptr(unsafe.Pointer(d))
    // Note that the special return, which does not trigger a delayed call to the function
    return0()
}

func deferproc(siz int32, fn *funcval) {
  // arguments of fn fullow fn
    // Get the rsp register value of the caller function
    sp := getcallersp()
    argp := uintptr(unsafe.Pointer(&fn)) + unsafe.Sizeof(fn)
    // Get the pc(rip) register value of the caller function
    callerpc := getcallerpc()

    // allocate struct _defer memory structure
    d := newdefer(siz)
    if d._panic ! = nil {
        throw("deferproc: d.panic ! = nil after newdefer")
    }
    // _defer structure initialization
    d.fn = fn
    d.pc = callerpc
    d.sp = sp
    switch siz {
    case 0:
        // Do nothing.
    case sys.PtrSize:
        *(*uintptr)(deferArgs(d)) = *(*uintptr)(unsafe.Pointer(argp))
    default:
        memmove(deferArgs(d), unsafe.Pointer(argp), uintptr(siz))
    }
    // Note that the special return, which does not trigger a delayed call to the function
    return0()
}

func deferreturn(arg0 uintptr) {
    gp := getg()
    // Get the top _defer node
    d := gp._defer
    // function recursion termination condition (d chain table traversal complete)
    if d == nil {
        return
    }
    // Get the rsp register value of the caller function
    sp := getcallersp()
    if d.sp ! = sp {
        // if _defer.sp does not match the caller's sp value, then return it directly.
        // Because of this, it means that the _defer structure is not registered with the caller function  
        return
    }

    switch d.siz {
    case 0:
        // Do nothing.
    case sys.PtrSize:
        *(*uintptr)(unsafe.Pointer(&arg0)) = *(*uintptr)(deferArgs(d))
    default:
        memmove(unsafe.Pointer(&arg0), deferArgs(d), uintptr(d.siz))
    }
    // Get the address of the delayed callback function
    fn := d.fn
    d.fn = nil
    // remove the current _defer node from the chain
    gp._defer = d.link
    // free the _defer memory (mainly the heap will need to handle it, the stack is reclaimed as the function finishes executing and the stack shrinks)
    freedefer(d)
    // execute delayed callback function
    jmpdefer(fn, uintptr(unsafe.Pointer(&arg0)))
}

package main

func main() {
    var x = 1
    defer println(x)
    x += 2
    return
}

func deferreturn(arg0 uintptr) {

    switch d.siz {
    case 0:
        // Do nothing.
    case sys.PtrSize:
        *(*uintptr)(unsafe.Pointer(&arg0)) = *(*uintptr)(deferArgs(d))
    default:
        memmove(uns1) The process of calling the function
To understand this process, it is first necessary to know the process of function invocation: the
a line of function call statements in go is actually a non-atomic operation, corresponding to multiple lines of assembly instructions, including 1) parameter setting and 2) call instruction execution.
where the call assembly instruction also has two elements: the return address stack (which causes the rsp value to grow downward, rsp-0x8), and the callee function address loaded into the pc register.
go's one-line function return statement is actually a non-atomic operation, corresponding to multiple lines of assembly instructions, including 1) return value setting and 2) ret instruction execution.
where the contents of the ret assembly instruction are two, the instruction pc register is restored to the address saved at the top of the rsp stack, and rsp is scaled up, rsp+0x8.
where the arguments are set in the caller function and the return value is set in the callee function.
the two registers rsp, rbp are the two most important registers of the stack frame, the values of which delimit the stack frame.
The most important point: Go's return call is a compound operation that can correspond to the following two sequences of operations.
Set the return value
The ret instruction jumps to the caller function
2) Does the return return the value first or does the defer function execute first?
The official Golang documentation clearly states that
That is, if the surrounding function returns through an explicit return statement, deferred functions are executedafter any result parameters are set by that return statementbutbefore the function returns to its caller.
That is, defer's function chain call is made after the return value is set but before the run instruction context returns to the caller function.
So the function containing the defer registration, after the return statement is executed, corresponds to the execution of three sequences of operations.
Set the return value
Execute the defer chain
The ret instruction jumps to the caller function
So, based on this principle, let's parse the following behavior.
func f1 () (r int) {
    t := 1
    defer func() {
        t = t + 5
    }()
    return t
}

func f2() (r int) {
    defer func(r int) {
        r = r + 5
    }(r)
    return 1
}

func f3() (r int) {
    defer func () {
        r = r + 5
    } ()
    return 1
}

What is the return value of each of these three functions?
Answer: f1() -> 1, f2() -> 1, f3() -> 6 .
a) After the function f1 executes the return t statement.
sets the return value r = t, when the value of the local variable t is equal to 1, so r = 1.
execute the defer function with t = t+5, after which the value of the local variable t is 6.
executes the assembly ret instruction, which jumps to the caller function.
So, the return value of f1() is 1; the
b) After the f2 function executes the return 1 statement.
set the return value r = t, when the value of the local variable t is equal to 1, so r = 1.
execute the defer function with t = t+5, after which the value of the local variable t is 6.
executes the assembly ret instruction, which jumps to the caller function.
So, the return value of f2() is still 1; the
c) After the f3 function executes the return 1 statement.
sets the return value r = 1.
execute the defer function with r = r+5, after which the return value of the variable r is 6 (this is a closure function, note the distinction from f2).
executes the assembly ret instruction, which jumps to the caller function.
So, the return value of f1() is 6.
the defer keyword implementation corresponds to the _defer data structure, which was always allocated on the heap during go1.1 - go1.12, and was optimized to allocate the _defer structure on the stack after go1.13, with significant performance improvements.
_defer is allocated on the stack in most scenarios, but will be allocated on the heap in loop nesting scenarios, so pay attention to defer usage scenarios when programming, otherwise there may be performance problems.
_defer corresponds to a registered deferred callback function (defer), the arguments and return value of the defer function follow _defer, which can be interpreted as the header, _defer and the memory where the function arguments and return value are located is a contiguous space, where _defer.siz specifies the size of the space occupied by the arguments and return value.
functions registered by defer in the same concatenation, all hanging in a chain table with goroutine._defer as the header.
The new element is inserted at the top, and the iteration is executed from the top to the bottom. So defer-registered functions have the LIFO characteristic, i.e., the later-registered ones are executed first.
different functions are on this chain, distinguished by _defer.sp.
The arguments to defer are pre-calculated, that is, they are confirmed when the defer keyword is executed, and the assignment is behind the memory block of _defer. when executed, copied to the corresponding location on the stack frame.
return corresponds to a compound operation with 3 actions: set return value, execute defer function chain, and ret instruction jump.
Reference.
Programming Library go Language Tutorial
.
This article about the Go defer principle and source code analysis is introduced here, more related Go defer principle content please search the previous articles of the Codedevlib or continue to browse the following related articles hope you support the Codedevlib more in the future!