HTTP 请求的 `Conn` 连接的 `ActiveConn` 是一个 map 数据结构，这种设计会导致并发访问问题吗？

对于一个Golang开发者来说，牢固扎实的基础是十分重要的，golang学习网就来带大家一点点的掌握基础知识点。今天本篇文章带大家了解《HTTP 请求的 `Conn` 连接的 `ActiveConn` 是一个 map 数据结构，这种设计会导致并发访问问题吗？》，主要介绍了，希望对大家的知识积累有所帮助，快点收藏起来吧，否则需要时就找不到了！

go http.request.context.activeconn是一个map，会不会有并发map的问题？

如果有很多连接，我打印request.context，其中包含一个activeconn(map)，会不会有并发读写map的问题？

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintf(w, "r.ctx: %#v, %+v", r.Context(), r.Context())
    })
    http.ListenAndServe(":1234", nil)
}

我使用webench进行压力测试，由于并发map问题而失败。那么，有没有人遇到同样的问题呢？就因为这样，我搞乱了核心服务……

解决方案

go 的 http 服务器实现的全部目的是处理并发连接，因此我怀疑您会在实现本身中看到并发问题。

这里发生的情况是，当在那里打印整个 r.context() 时，您最终会访问 go 的 server 对象的内部字段，而不同步对其的访问。

这会导致您最终看到 concurrent map read 和 map write 错误。

最简单的解决方案是替换它：

fmt.fprintf(w, "r.ctx: %#v, %+v", r.context(), r.context())

通过您编写的一些自定义函数，该函数采用 context 对象并提取与您相关的值（例如，您自己添加到上下文中的任何自定义键/值）。

有关 activeconn 字段的更详细说明

当你打印整个 r.context() 时看到的 activeconn ，来自 go 的 server 类型。

当准备侦听连接时，server 创建一个基本上下文，在其中添加对 server 本身的引用：

https://github.com/golang/go/blob/master/src/net/http/server.go#L2894

func (srv *server) serve(l net.listener) error {
    ....
    ctx := context.withvalue(basectx, servercontextkey, srv)
    ....
}

因此，在打印整个上下文时，您最终会打印 activeconn 字段：

https://github.com/golang/go/blob/master/src/net/http/server.go#L2582

activeconn map[*conn]struct{}

server 实现会在需要使用该地图时同步对该地图的访问，例如此处：

https://github.com/golang/go/blob/master/src/net/http/server.go#L2997

...

s.mu.Lock()
defer s.mu.Unlock()
if s.activeConn == nil {
    s.activeConn = make(map[*conn]struct{})
}

if add {
    s.activeConn[c] = struct{}{}
} else {
    delete(s.activeConn, c)
}
....

好了，本文到此结束，带大家了解了《HTTP 请求的 `Conn` 连接的 `ActiveConn` 是一个 map 数据结构，这种设计会导致并发访问问题吗？》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！