title: Are there any advantages to having a defer in a simple, no return, non-panicking function?
body: <p>Going through the standard library, I see a lot functions similar to the following:</p>
  
  <pre><code>// src/database/sql/sql.go
  func (dc *driverConn) removeOpenStmt(ds *driverStmt) {
      dc.Lock()
      defer dc.Unlock()
      delete(dc.openStmt, ds)
  }
  ...
  
  func (db *DB) addDep(x finalCloser, dep interface{}) {
      //println(fmt.Sprintf("addDep(%T %p, %T %p)", x, x, dep, dep))
      db.mu.Lock()
      defer db.mu.Unlock()
      db.addDepLocked(x, dep)
  }
  // src/expvar/expvar.go
  func (v *Map) addKey(key string) {
      v.keysMu.Lock()
      defer v.keysMu.Unlock()
      v.keys = append(v.keys, key)
      sort.Strings(v.keys)
  }
  // etc...
  </code></pre>
  
  <p>I.e.: simple functions with no returns and presumably no way to panic that are still deferring the unlock of their mutex. As I understand it, the overhead of a <code>defer</code> has been improved (and perhaps is still in the process of being improved), but that being said: <strong>Is there any reason to include a <code>defer</code> in functions like these?  Couldn't these types of defers end up slowing down a high traffic function?</strong></p>