Walmart

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.

HashMap keeps an array of buckets (Node<K,V>[] table). The key's hashCode() is spread, masked to an index, and the entry is stored in that bucket as a linked list (or a red-black tree when large). Lookup compares hash then equals.

• Index = (n - 1) & hash where n is a power of two.
• Spread function: h ^ (h >>> 16) mixes high bits into low bits.
• Default capacity 16, load factor 0.75.
• Allows one null key and many null values; not thread-safe.

No. Declarative transactions are applied by a proxy around a Spring bean. The proxy only intercepts calls arriving through it to methods it can override, so new-created objects, private, and final methods (CGLIB cannot override them) get no transaction and fail silently.

• Annotate public methods on beans; since Spring 6, protected and package-private methods are also supported with class-based (CGLIB) proxies.
• Check with TransactionSynchronizationManager.isActualTransactionActive() or by logging org.springframework.transaction at DEBUG.
• Put @Transactional on the service layer, not controllers or repository interfaces' callers' internals.

Self-invocation bypasses the proxy, so the REQUIRES_NEW annotation is never evaluated; saveAudit() runs inside the caller's transaction and rolls back with it.

Fix by moving it to a separate bean:

@Service
class AuditService {
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void save(AuditEvent e) { repo.save(e); }
}

Alternatives: self-injection, TransactionTemplate inside the method, or AspectJ mode.

By default Spring rolls back only on unchecked exceptions (RuntimeException and Error). A checked exception commits whatever was flushed. Declare rollbackFor = Exception.class (or specific types) to roll back on checked ones.

@Transactional(rollbackFor = IOException.class)
public void importFile(Path p) throws IOException { ... }

This rule mirrors EJB convention. noRollbackFor does the inverse.

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).

Model ParkingLot with floors of typed spots, issue a Ticket on entry, compute a fee by strategy on exit.

• Requirements: multiple floors, vehicle types (bike, car, truck), spot types, entry/exit gates, hourly pricing, full-lot handling.
• Entities: ParkingLot, Floor, Spot (type, occupied), Vehicle, Ticket, FeeStrategy, SpotAllocationStrategy (nearest, lowest floor).
• Concurrency: two cars must not get the same spot; use an atomic tryOccupy() per spot (CAS) or a lock per floor.
• Extensions: EV charging spots, reservations, payment, display boards (Observer).

class Spot {
    private final AtomicBoolean taken = new AtomicBoolean();
    final SpotType type;
    Spot(SpotType t){ type = t; }
    boolean tryOccupy(){ return taken.compareAndSet(false, true); }
    void free(){ taken.set(false); }
}
class ParkingLot {
    Optional<Ticket> park(Vehicle v, Instant now) {
        for (Floor f : floors)
            for (Spot s : f.spotsFor(v.type()))
                if (s.tryOccupy()) return Optional.of(new Ticket(UUID.randomUUID(), v, s, now));
        return Optional.empty();
    }
}

• Fee: FeeStrategy.compute(Duration) with hourly slabs; pick via vehicle type.
• Keep free spots in a queue per type for O(1) allocation instead of scanning.