Golang gRPC服务端并发机制咨询：goroutine使用与HTTP/2依赖问题

Awesome question—let's unpack how Go's gRPC handles concurrency, since this is a common point of curiosity for folks working with the framework.

Does the gRPC server create a new goroutine for each method call? #

By default, yes. Every incoming RPC request (whether it's a unary call, server streaming, client streaming, or bidirectional streaming) gets its own dedicated goroutine to execute the corresponding service method.

For example, if 100 clients hit your GetUser unary RPC at the same time, the server will spin up 100 separate goroutines to handle each call independently. This is the out-of-the-box behavior, though you can tweak limits (like max concurrent streams) via grpc.ServerOption if you need to cap overall concurrency.

Goroutine per request vs. goroutine pool? #

Go's gRPC implementation does not use a goroutine pool by default—it sticks strictly to the "one goroutine per request" model. Here's why this works so well:

• Goroutines in Go are extremely lightweight (starting with just a 2KB stack that grows/shrinks dynamically), so the overhead of creating and destroying them is negligible compared to OS threads.
• Go's runtime already manages goroutine scheduling efficiently via its M:N scheduler, so adding a pool would introduce unnecessary complexity without meaningful performance gains.

That said, if you have strict concurrency limits you need to enforce (e.g., to prevent overwhelming downstream databases or APIs), you can implement your own goroutine pool inside your service methods or use a middleware layer to throttle requests. But this is application-level logic, not part of the gRPC framework itself.

Does this mechanism depend on HTTP/2's concurrency model? #

Absolutely—this approach is deeply tied to HTTP/2's core capabilities. gRPC is built entirely on top of HTTP/2, which supports multiplexing hundreds of concurrent streams over a single TCP connection. Each RPC request maps directly to an HTTP/2 stream.

When the gRPC server receives a new HTTP/2 stream (i.e., a new RPC request), it spins up a goroutine to handle that stream's entire lifecycle. HTTP/2's multiplexing lets gRPC scale efficiently without opening thousands of TCP connections, and Go's goroutines provide the lightweight concurrency needed to match that scale without bogging down the server.

For streaming RPCs, the entire session—from initial request to final stream closure—runs within the same goroutine assigned to that request.

内容的提问来源于stack exchange，提问作者kingluo