这里主要是总结 defer 语句的一些使用场景.

1. 简化资源的回收

这是最常见的 defer 用法. 比如:

• 
  
  mu.Lock()
  
  
• 
  
  defer mu.Unlock()
  
  
  

当然, defer 也有一定的开销, 也有为了节省性能而回避使用的 defer 的:

• 
  
  mu.Lock()
  
  
• 
  
  count++
  
  
• 
  
  mu.Unlock()
  
  
  

从简化资源的释放角度看, defer 类似一个语法糖, 好像不是必须的.

2. panic异常的捕获

defer 除了用于简化资源的释放外, 还是Go语言异常框架的一个组成部分.

Go语言中, panic用于抛出异常, recover用于捕获异常.

recover只能在defer语句中使用, 直接调用recover是无效的.

比如:

• 
  
  func main() {
  
  
• 
  
      f()
  
  
• 
  
      fmt.Println("Returned normally from f.")
  
  
• 
  
  }
  
  
• 
  
  
  
  
• 
  
  func f() {
  
  
• 
  
      defer func() {
  
  
• 
  
          if r := recover(); r != nil {
  
  
• 
  
              fmt.Println("Recovered in f", r)
  
  
• 
  
          }
  
  
• 
  
      }()
  
  
• 
  
      fmt.Println("Calling g.")
  
  
• 
  
      g()
  
  
• 
  
      fmt.Println("Returned normally from g.")
  
  
• 
  
  }
  
  
• 
  
  
  
  
• 
  
  func g() {
  
  
• 
  
      panic("ERROR")
  
  
• 
  
  }
  
  
  

因此, 如果要捕获Go语言中函数的异常, 就离不开defer语句了.

3. 修改返回值

defer 除了用于配合 recover, 用于捕获 panic 异常外,defer还可以用于在 return 之后修改函数的返回值.

比如:

• 
  
  func doubleSum(a, b int) (sum int) {
  
  
• 
  
      defer func() {   //该函数在函数返回时  调用
  
  
• 
  
          sum *= 2
  
  
• 
  
      }()
  
  
• 
  
      sum = a + b
  
  
• 
  
  }
  
  
  

当然, 这个特性应该只是 defer 的副作用, 具体在什么场景使用就要由开发者自己决定了.

4. 安全的回收资源

前面第一点提到, defer 最常见的用法是简化资源的回收. 而且, 从资源回收角度看,
defer 只是一个语法糖.

其实, 也不完全是这样, 特别是在涉及到第二点提到的panic异常等因素导致goroutine提前退出时.

比如, 有一个线程安全的slice修改函数, 为了性能没有使用defer语句:

• 
  
  func set(mu *sync.Mutex, arr []int, i, v int) {
  
  
• 
  
      mu.Lock()
  
  
• 
  
      arr = v
  
  
• 
  
      mu.Unlock()
  
  
• 
  
  }
  
  
• 
  
  
  
  
  

但是, 如果 i >= len(arr)的话, runtime就会抛出切片越界的异常(这里只是举例, 实际开发中不应该出现切片越界异常). 这样的话, mu.Unlock() 就没有机会被执行了.

如果用defer的话, 即使出现异常也能保证mu.Unlock()被调用:

• 
  
  func set(mu *sync.Mutex, arr []int, i, v int) {
  
  
• 
  
      mu.Lock()
  
  
• 
  
      defer mu.Unlock()
  
  
• 
  
      arr = v
  
  
• 
  
  }
  
  
• 
  
  
  
  
  

当然, Go语言约定异常不会跨越package边界. 因此, 调用一般函数的时候不用担心goroutine异常退出的情况.

不过对于一些比较特殊的package, 比如go test依赖的testing包, 包中的t.Fatal就是依赖了Go中类似异常的特性(准确的说是调用了runtime.Goexit()).

比如有以下的测试函数(详情请参考Issue5746):

• 
  
  func TestFailed(t *testing.T) {
  
  
• 
  
      var wg sync.WaitGroup
  
  
• 
  
      for i := 0; i < 2; i++ {
  
  
• 
  
          wg.Add(1)
  
  
• 
  
          go func(id int) {
  
  
• 
  
              // defer wg.Done()
  
  
• 
  
              t.Fatalf("TestFailed: id = %v\n", id)
  
  
• 
  
              wg.Done()
  
  
• 
  
          }(i)
  
  
• 
  
      }
  
  
• 
  
      wg.Wait()
  
  
• 
  
  }
  
  
  

当测试失败的时候, wg.Done()将没有机会执行, 最终导致wg.Wait()死锁.

对于这个例子, 安全的做法是使用defer语句保证wg.Done()始终会被执行.

转自：http://my.oschina.net/chai2010/blog/140065

#######################################

本文实例讲述了GO语言延迟函数defer用法。分享给大家供大家参考。具体分析如下：

defer 在声明时不会立即执行，而是在函数 return 后，再按照 FILO （先进后出）的原则依次执行每一个 defer.

defer一般用于异常处理、释放资源、清理数据、记录日志等。这有点像面向对象语言的析构函数，优雅又简洁，是 Golang 的亮点之一。

代码1：了解 defer 的执行顺序

[url=]复制代码[/url]代码如下:
package main

import "fmt"

func fn(n int) int {
defer func() {
  n++
  fmt.Println("3st:", n)
}()

defer func() {
  n++
  fmt.Println("2st:", n)
}()

defer func() {
  n++
  fmt.Println("1st:", n)
}()

return n //没有做任何事情
}

func main() {
fmt.Println("函数返回值：", fn(0))
}

输出：

1st: 1
2st: 2
3st: 3
函数返回值： 0

代码2：经典应用实例

[url=]复制代码[/url]代码如下:
func CopyFile(dst, src string) (w int64, err error) {
srcFile, err := os.Open(src)
if err != nil {
  return
}
defer srcFile.Close() //每次申请资源时，请习惯立即申请一个 defer 关闭资源，这样就不会忘记释放资源了

dstFile, err := os.Create(dst)
if err != nil {
  return
}
defer dstFile.Close()

return io.Copy(dstFile, srcFile)
}

【转载】仅作分享，侵删

链接：https://blog.csdn.net/zzhongcy/article/details/50395415

奈斯