which bufio Reader / Writer are you referring to?
Do you have code to demonstrate the issue?

code

package main

import (
	"github.com/lxzan/gws"
	"log"
	"net/http"
	_ "net/http/pprof"
)

func main() {
	handler := new(Handler)

	upgrader := gws.NewUpgrader(handler, nil)

	http.HandleFunc("/connect", func(writer http.ResponseWriter, request *http.Request) {
		socket, err := upgrader.Accept(writer, request)
		if err != nil {
			log.Println(err.Error())
			return
		}
		go socket.Listen()
	})

	if err := http.ListenAndServe(":8000", nil); err != nil {
		log.Panic(err.Error())
	}
}

type Handler struct {
	gws.BuiltinEventHandler
}

func (c *Handler) OnPing(socket *gws.Conn, payload []byte) {
	socket.WritePong(payload)
}

func (c *Handler) OnMessage(socket *gws.Conn, message *gws.Message) {
	defer message.Close()
	socket.WriteMessage(message.Opcode, message.Data.Bytes())
}

Test Command

tcpkali -c 10000 --connect-rate 500 -r 1 -T 3000s -m 'hello' --ws 127.0.0.1:8000/connect

pprof

I believe this is working as intended.
The bufio.Writer is placed in a sync.Pool for reuse and may be cleared at a later time.
https://github.com/golang/go/blob/master/src/net/http/server.go#L2086

Never mind, I have implemented a websocket server based on tcp independently, and the memory footprint is significantly reduced.

Hi @seankhliao, the returning of a write buffer you likely pointed at, http.response.w, is for the buffer used in chunked-encoding. It is one of two write buffers that are used as part of the request/response life cycle.

The other write buffer is attached to the connection, http.conn.bufw, and it remains unused after hijacking.

As part of the hijack process, the connection read buffer, http.conn.bufr, will be re-used and returned to the hijack caller. A new write buffer will be allocated and returned to the caller.

I do not see a need for allocating a new write buffer as part of the hijack process. After hijacking a connection, no further writes can be made via the http.response methods.
So we might as well re-use the connection write buffer and return it to the hijack caller. WDYT @seankhliao?

The net/http unit tests are happy with the following patch and BenchmarkServerHijack records a reduction of two allocations worth 4172 bytes per operation (the 4096B buffer slice and a struct for the buffer).

Patch: 25b0691

diff --git a/src/net/http/server.go b/src/net/http/server.go
index 9245778590..0ba55e8ee5 100644
--- a/src/net/http/server.go
+++ b/src/net/http/server.go
@@ -322,7 +322,7 @@ func (c *conn) hijackLocked() (rwc net.Conn, buf *bufio.ReadWriter, err error) {
        rwc = c.rwc
        rwc.SetDeadline(time.Time{})
 
-       buf = bufio.NewReadWriter(c.bufr, bufio.NewWriter(rwc))
+       buf = bufio.NewReadWriter(c.bufr, c.bufw)
        if c.r.hasByte {
                if _, err := c.bufr.Peek(c.bufr.Buffered() + 1); err != nil {
                        return nil, nil, fmt.Errorf("unexpected Peek failure reading buffered byte: %v", err)

goos: linux
goarch: amd64
pkg: net/http
cpu: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz
               │   old.txt   │               new.txt               │
               │   sec/op    │   sec/op     vs base                │
ServerHijack-8   13.28µ ± 2%   10.84µ ± 3%  -18.36% (p=0.000 n=10)

               │   old.txt    │               new.txt                │
               │     B/op     │     B/op      vs base                │
ServerHijack-8   15.84Ki ± 0%   11.77Ki ± 0%  -25.70% (p=0.000 n=10)

               │  old.txt   │              new.txt              │
               │ allocs/op  │ allocs/op   vs base               │
ServerHijack-8   50.00 ± 0%   48.00 ± 0%  -4.00% (p=0.000 n=10)

I can open a PR with the patch in case you are happy with the approach, @seankhliao.

Change https://go.dev/cl/634855 mentions this issue: net/http: reduce memory usage when hijacking