Scenario 1: Unpredictable Thread Pool Rejection in Batch Processing

Developers often combine thread pools with coordination utilities like CountDownLatch to process data in chunks. On the surface, the implementation appears flawless. However, under specific conditions, this pattern can trigger intermittent RejectedExecutionException errors, baffling many during production debugging.

Consider the following batch processing setup. The goal is to partition a large dataset into smaller chunks and submit them to a fixed-size thread pool, waiting for each chunk to complete before moving to the next.

import java.util.List;
import java.util.concurrent.*;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

public class BatchProcessor {

    // Core threads: 8, Max threads: 8, Queue capacity: 8
    // Total capacity before rejection: 16 tasks
    private static final ThreadPoolExecutor taskExecutor = new ThreadPoolExecutor(
            8, 8, 0L, TimeUnit.MILLISECONDS,
            new ArrayBlockingQueue<>(8)
    ) {
        @Override
        protected void afterExecute(Runnable r, Throwable t) {
            // Simulating internal cleanup/recycling latency
            try { Thread.sleep(100); } catch (InterruptedException ignored) {}
            super.afterExecute(r, t);
        }
    };

    public static void main(String[] args) throws InterruptedException {
        List<Integer> inputDataset = IntStream.range(0, 200).boxed().collect(Collectors.toList());
        int partitionSize = inputDataset.size() / 10; // 20 items per batch

        for (int i = 0; i < 10; i++) {
            List<Integer> currentChunk = inputDataset.subList(i * partitionSize, (i + 1) * partitionSize);
            CountDownLatch latch = new CountDownLatch(currentChunk.size());

            for (Integer item : currentChunk) {
                taskExecutor.submit(() -> {
                    try {
                        Thread.sleep(50); // Simulate business logic
                    } catch (InterruptedException e) {
                        Thread.currentThread().interrupt();
                    } finally {
                        latch.countDown();
                    }
                });
            }

            // Main thread blocks until all tasks in the current batch finish
            latch.await();
            System.out.println("Chunk processed: " + i);
        }
        taskExecutor.shutdown();
    }
}

The logic relies on latch.await() to synchronize batches. The main thread should only submit the next batch once all worker threads have signaled completion via countDown(). Why would the pool ever fill up and trigger rejection?

The root cause lies in the internal lifecycle of ThreadPoolExecutor worker threads. When a worker finishes executing a task, the following sequence occurs:

1. The task's run() method completes.
2. countDown() is called, releasing the main thread.
3. The worker thread does not immediately become available. It must execute post-execution hooks (like afterExecute), handle exceptions, and eventually loop back to block on getTask() to await new work.

This creates a microscopic race condition. The main thread is unblocked and immediately tries to submit the next batch. If the submission occurs before the worker threads have finished their cleanup and blocked on the work queue, the thread pool incorrectly perceives all threads as busy. Combined with a full queue, the pool hits its maximum capacity and invokes the rejection policy.

Increasing the queue size masks the issue by buffering the overflow, giving worker threads enough time to recycle. To reliably reproduce the race condition, simulating cleanup overhead via afterExecute (as shown in the code) forces the rejection to occur deterministically, confirming the timing dependency.

Scenario 2: The Myth of Lock Release Timing with Try-Finally and Transactions

A common architectural dilemma involves combining explicit locking mechanisms (like ReentrantLock or distributed locks) with declarative transactions (@Transactional). A frequent misconception arises regarding the execution order when try-finally and return statements are combined with transactional methods.

The alleged issue suggests that wrapping a transactional method call inside a try block with a finally unlock clauce causes the lock to be released before the transaction commits, potentially leading to data inconsistencies or premature resource exposure.

Let's dissect the actual execution flow based on JVM specifications and Spring AOP proxy mechanics.

Consider this structure:

if (lock.tryLock()) {
    try {
        return service.executeTransactionalLogic();
    } finally {
        lock.unlock();
    }
}

**JVM Evaluation Order:**The Java Language Specification dictates that when a return statement is encountered in side a try block that has an associated finally block:

1. The return expression is evaluated, and the resulting value is temporarily stored in the local variable array.
2. Control transfers to the finally block.
3. The finally block executes completely (in this case, releasing the lock).
4. The stored value is returned to the caller.

Thus, unlock() definitively executes before the method physically returns to its caller.

**Spring Transaction Proxy Behavior:**Spring's @Transactional does not execute inline. It relies on AOP proxies that wrap the target method. The proxy's interception logic roughly follows this patern:

1. Start transaction.
2. Invoke target method (which includes our try-finally-return block).
3. If target method returns successfully -> Commit transaction.
4. If target method throws exception -> Rollback transaction.

Because the finally block runs during step 2 (inside the target method invocation), the lock is indeed released before the proxy executes step 3 (transaction commit).

While this execution order is technically accurate, it is generally not a bug in itself. The critical question is whether holding a lock during a database transaction is a sound design pattern. Typically, it is discouraged because it prolongs lock holding time, increasing contention and deadlocking risks.

To maintain clean separation of concerns and predictable transaction boundaries, the recommended approach isolates lock management from transaction scope:

@Service
public class OrderProcessor {
    
    private final Lock itemLock = new ReentrantLock(true);

    public OrderResult processOrder(Long orderId) {
        // Acquire lock in the non-transactional wrapper
        itemLock.lock();
        try {
            // Delegate to the transactional method
            return performDbOperations(orderId);
        } finally {
            itemLock.unlock();
        }
    }

    @Transactional(rollbackFor = Exception.class)
    protected OrderResult performDbOperations(Long orderId) {
        // Database operations execute within a bounded transaction scope
        // Lock is already held, but transaction commit happens here
        return new OrderResult(orderId, "SUCCESS");
    }
}

By structuring the code this way, the lock guards the entire operation, including the transaction commit, while keeping the try-finally semantics explicit and easy to audit. The takeaway is to never rely on assumptions about framework execution order; instead, map out the exact proxy invocation chain and JVM bytecode evaluation rules to validate concurrency patterns.