Why are thread pools and connection pools considered good uses of pooling, when pooling ordinary objects is discouraged?

## The core distinction: resource vs value Pooling advice isn't contradictory — it depends on *what* you're pooling. Split objects into two categories: - **Resources** — things with an expensive lifecycle or a hard supply limit. - **Values** — ordinary, cheap, in-process objects. Pooling pays for resources and costs for values. Threads and connections are the canonical resources. ## Why a thread is expensive A Java `Thread` is backed by an **OS thread**. Creating one involves: - Allocating a sizable stack (often ~512KB–1MB of address space). - Creating kernel data structures and registering with the OS scheduler. - Context-switch and scheduling overhead once running. Spawning a fresh thread per task would be slow and could exhaust memory under load. A **thread pool** (`ExecutorService`) creates a bounded set of threads once and feeds them a queue of tasks, so the expensive creation happens rarely. It also **bounds concurrency**, which protects the machine from being overwhelmed (e.g. thousands of simultaneous threads thrashing the scheduler). ## Why a connection is expensive A database or HTTP connection requires: - A **TCP handshake** (round trips to establish the socket). - **Authentication** with the server. - Often **TLS negotiation** (more round trips, crypto setup). - Server-side per-connection resources (memory, session state). That's tens of milliseconds and real server load *per* connection. Databases also cap how many connections they accept. A **connection pool** (e.g. HikariCP) keeps a bounded set of open, authenticated connections and hands them out, so requests skip the handshake and the database isn't flooded. The pool's size limit is itself a feature: it protects the database from too many concurrent connections. ## Why ordinary objects are different An ordinary Java object: - Allocates via a **TLAB pointer bump** — a few instructions, no lock. - Dies in the **young generation**, reclaimed nearly for free by a minor GC. - May even be **eliminated entirely** by the JIT's escape analysis. There's almost no creation cost to amortize, and no scarce supply to protect. Pooling it instead adds borrow/return synchronization, stale-state and leak hazards, and promotes the object to the costlier old generation. So the cost/benefit flips. ## The unifying rule > Pool when creation is *expensive* or the resource is *scarce/limited*. Threads (expensive + need bounding) and connections (expensive + scarce + need bounding) qualify; plain objects (cheap + unlimited) do not. ## A note on virtual threads Modern Java's **virtual threads** are deliberately *cheap* to create — so the guidance is to **not** pool them, treating them more like values. This reinforces the rule: pool the expensive thing, not the cheap thing. (Connection pooling is still needed because the database connection behind the work is still scarce and expensive.) ## Takeaway Thread and connection pools are good because they reuse genuinely expensive, scarce resources and double as concurrency throttles. The same logic that justifies them — high creation cost and limited supply — is exactly what ordinary objects lack, which is why pooling plain objects is discouraged.