Bank of America

The executor tries three things in a fixed order: start a core thread, then enqueue, and only when the queue refuses the task start a non-core thread up to maximumPoolSize; if that also fails the RejectedExecutionHandler runs. With an unbounded queue offer() never refuses, so the pool is stuck at corePoolSize and maximumPoolSize is dead configuration.

1. workers < corePoolSize: spawn a worker for this task, even if other core threads are idle.
2. Otherwise workQueue.offer(task); success means an idle worker will take() it later.
3. Queue full and workers < maximumPoolSize: spawn a non-core worker (reclaimed after keepAliveTime).
4. Otherwise reject: AbortPolicy (throws), CallerRunsPolicy (caller executes, natural backpressure), DiscardPolicy, DiscardOldestPolicy.

ExecutorService pool = new ThreadPoolExecutor(
    5, 50, 60, TimeUnit.SECONDS,
    new ArrayBlockingQueue<>(200),            // bounded: max threads become reachable
    new ThreadPoolExecutor.CallerRunsPolicy()); // slows producers instead of dropping

Under a spike with the unbounded queue the symptom is rising latency and heap (queued tasks), not rejected tasks. With a bounded queue the pool reaches 5 + 50 threads only after 200 tasks are queued.

JOIN FETCH loads the association in the same SQL join and initializes it on the returned entities, so the loop does no further queries.

@Query("select o from Order o join fetch o.customer where o.status = :s")
List<Order> findWithCustomer(OrderStatus s);

• Plain join fetch is an inner join; use left join fetch to keep parents with no children.
• Fetching a collection multiplies rows (Cartesian product); Hibernate 6 de-duplicates parent entities automatically, so distinct is no longer needed for that purpose (it only affects SQL if you want it).
• You cannot alias-filter a fetched collection reliably; filtering it makes the in-memory collection incomplete.

When a lazy association of one entity is touched, Hibernate initializes the same association for up to N other uninitialized entities in the persistence context using where id in (?, ?, ...). 101 queries become 1 + ceil(100/N).

• Set globally: spring.jpa.properties.hibernate.default_batch_fetch_size=32.
• It works for collections and lazy to-one proxies, and composes with pagination because the parent query keeps its LIMIT.
• Hibernate 6 may pad IN lists to powers of two for statement-cache reuse (in_clause_parameter_padding).