在简单,无回报,无恐慌的功能中延迟是否有任何优势？

Question

通过标准库,我看到很多类似于以下的功能:

// 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...

即:简单的功能,没有返回,可能没有办法恐慌,仍然推迟他们的互斥锁的解锁.据我所知,a的开销defer已得到改善(可能仍在改进过程中),但话虽如此:是否有任何理由defer在这些函数中加入？难道这些类型的延迟最终会减慢高流量功能吗？

Answer 1

总是推迟之类的东西Mutex.Unlock(),并WaitGroup.Done()在函数的顶部,使调试和维护更容易,因为你立即看到这些碎片被正确处理,所以你知道,那些重要的部分都被认真考虑,并能迅速转移到其他问题.

它在3行函数中并不是一个大问题,但一致的代码查找代码也更容易阅读.然后随着代码的增长,您不必担心添加可能会出现恐慌的表达式,或者复杂的早期返回逻辑,因为预先存在的延迟将始终正常工作.