golang 资源所有权模式（文件、连接、关闭权限）

Question

在 golang 中管理资源所有权的正确方法是什么？假设我有以下内容：

db, err := sql.Open("mysql", "role@/test_db")
am := NewResourceManager(db)
am.DoWork()
db.Close()

总是让调用函数维护关闭资源的所有权和责任是典型的吗？这对我来说感觉有点奇怪，因为在关闭后，am仍然保留一个引用，db如果我或其他人稍后不小心，可以尝试使用（我想这是延迟的情况；但是，如果我想将 ResourceManager 传am回从这个块，我什至如何正确推迟文件的关闭？我实际上希望它在这个块完成执行时保持打开状态）。我发现在其他语言中，我经常希望允许实例管理资源，然后在调用析构函数时将其清理干净，就像这个玩具 python 示例：

class Writer():
   def __init__(self, filename):
       self.f = open(filename, 'w+')

   def __del__(self):
       self.f.close()

   def write(value):
       self.f.write(value)

不幸的是，golang 中没有析构函数。除了这样的事情，我不知道我会如何在 go 中做到这一点：

type ResourceManager interface {
   DoWork()
   // Close() ?
}

type resourceManager struct {
  db *sql.DB
}

func NewResourceManager(db *sql.DB) ResourceManager {
  return &resourceManager{db}
} 

db, err := sql.Open("mysql", "role@/test_db")
am := NewResourceManager(db)
am.DoWork()
am.Close()  // using method shortening

但这似乎不太透明，我不确定如何传达 ResourceManager 现在也需要 Close() 。我发现这是一个常见的绊脚石，即我还想要一个资源管理器来保存 gRPC 客户端连接，如果这些类型的资源不是由资源管理对象管理的，那么我的主要功能似乎是被大量的资源管理杂乱无章，即打开和关闭。例如，我可以想象这样一种情况，我不想main知道有关对象及其资源的任何信息：

...
func NewResourceManager() ResourceManager {
  db, err := sql.Open("mysql", "role@/test_db")
  return &resourceManager{db}
}
...
// main elsewhere
am := NewResourceManager()
am.DoWork()

Answer 1

您选择了一个糟糕的例子，因为您通常会重用一个数据库连接，而不是每次使用都打开和关闭一个。因此，您可以将 db 连接传递给使用它的函数，并在调用者中进行资源管理，而无需任何资源管理器：

// Imports etc omitted for the sake of readability

func PingHandler(db *sql.DB) http.Handler (
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
       if err := db.ping(); err != nil {
          http.Error(w,e.Error(),500)
       }
    })
)

func main(){
    db,_ := sql.Open("superdb",os.Getenv("APP_DBURL"))

    // Note the db connection will only be closed if main exits.
    defer db.Close()

    // Setup the server
    http.Handle("/ping", PingHandler(db))
    server := &http.Server{Addr: ":8080"}

    // Create a channel for listening on SIGINT, -TERM and -QUIT
    stop := make(chan os.Signal, 1)

    // Register channel to be notified on said signals
    signal.Notify(stop, syscall.SIGINT, syscall.SIGTERM, syscall.SIGQUIT)

    go func(){
            // When we get the signal...
            <- stop
            ctx, _ := context.WithTimeout(context.Background(), 5*time.Second)
            // ... we gracefully shut down the server.
            // That ensures that no new connections, which potentially
            // would use our db connection, are accepted.
            if err := server.Shutdown(ctx); err != nil {
                // handle err
            }
    }

    // This blocks until the server is shut down.
    // AFTER it is shut down, main exits, the deferred calls are executed.
    // In this case, the database connection is closed.
    // And it is closed only after the last handler call which uses the connection is finished.
    // Mission accomplished.
    server.ListenAndServe()
}

所以在这个例子中，不需要资源管理器，老实说，我想不出一个真正需要资源管理器的例子。在极少数情况下，我需要类似的东西，我使用sync.Pool.

但是，对于 gRPC 客户端连接，也不需要维护 pool，或者：

[...]但是，ClientConn 应该自己管理连接，因此如果连接中断，它将自动重新连接。如果您有多个后端，则可以连接到多个后端并在它们之间进行负载平衡。[...]

所以同样的原则适用：创建一个连接（池），根据需要传递它，确保在所有工作完成后关闭它。

去谚语：

清晰胜于聪明。

—罗伯特·派克

与其将资源管理隐藏在其他地方，不如尽可能将资源管理与使用它们的代码密切相关，并尽可能明确地进行管理。