在golang中管理资源所有权的正确方法是什么？假设我有以下内容：
db, err := sql.Open("mysql", "role@/test_db")
am := NewResourceManager(db)
am.DoWork()
db.Close()
是否通常始终让调用函数维护关闭资源的所有权和责任？这对我来说感觉有点奇怪，因为在关闭后，am仍然保留一个引用，如果我或其他人以后不小心，可以尝试使用db(我想这是一个推迟的情况;但是，如果我想从这个块传回 ResourceManageram，我什至如何正确延迟文件的关闭？我实际上希望它在这个块完成执行时保持打开状态(。我发现在其他语言中，我经常希望允许实例管理资源，然后在调用析构函数时清理它，就像这个玩具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 中没有析构函数。除了这样的事情之外，我不确定我会如何做到这一点：
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
但这似乎不太透明，我不确定如何传达资源管理器现在也需要 Close(('d。我发现这是一个常见的绊脚石，即我还想拥有一个保存 gRPC 客户端连接的资源管理器，如果这些类型的资源不是由资源管理对象管理的，那么似乎我的主要功能将被大量资源管理弄乱，即打开和关闭。例如，我可以想象一个情况，我不想让main知道关于对象及其资源的任何信息：
...
func NewResourceManager() ResourceManager {
db, err := sql.Open("mysql", "role@/test_db")
return &resourceManager{db}
}
...
// main elsewhere
am := NewResourceManager()
am.DoWork()
您选择了一个不好的示例，因为您通常会重用数据库连接，而不是每次使用都打开和关闭数据库连接。因此，您可以将数据库连接传递给使用它的函数，并在调用方中进行资源管理，而无需资源管理器：
// 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 客户端连接，也不需要维护池：
[...]但是，ClientConn 应该自己管理连接，因此如果连接断开，它将自动重新连接。如果您有多个后端，则可以连接到其中的多个后端并在它们之间进行负载平衡。[...]
所以同样的原则适用：创建一个连接(池(，根据需要传递它，确保在所有工作完成后关闭它。
去谚语：
清晰胜于聪明。
–罗伯特·派克
与其将资源管理隐藏在其他地方，不如尽可能靠近使用资源的代码来管理资源，并尽可能明确地管理资源。