Interview Reflections: HTTP GET Issue, Rate‑Limiting, and ThreadPool Mechanics

1. HTTP GET Issue Reflects Thinking Problem

The interview begins with a question: an HTTP request receives a JSON array of IDs, works in testing but fails in pre‑production. The candidate first asks whether the code is identical, then whether any ID contains Chinese characters, and whether it was a pressure test. The interviewer clarifies it was a single call, not a load test. After several guesses (caching, database failure) the candidate admits uncertainty and the interviewer asks how they usually handle bugs. The candidate outlines a systematic approach: locate logs, analyze, try solutions, repeat. The interviewer points out the caller’s log shows a 500 response, while the provider’s log only shows a long list of IDs, leading the candidate to suggest that the large number of IDs causes slow queries and recommends batch processing.

Insight 1 When information is insufficient, first obtain more complete data through effective communication rather than guessing.

2. Rate‑Limiting Question: Only Three Messages per Half‑Hour

The interviewer asks for an algorithm that allows a user to send at most three messages in any 30‑minute window, not simply one every ten minutes. The candidate initially mentions Guava’s RateLimiter and token‑bucket mechanism but cannot articulate the token maintenance. After reconsideration, the candidate explains that each request should update the token bucket based on elapsed time and a timestamp, allowing three tokens per 30 minutes. The solution is described as a table storing user ID, remaining token count, and last send time.

Insight 2 Classic algorithms, when applied flexibly, can solve most business problems.

3. ThreadPool Execution Principles

The interviewer asks the candidate to explain how a ThreadPoolExecutor is extended. The candidate lists core parameters (core size, max size, keep‑alive time, queue size, rejection policies) and enumerates the four standard policies: AbortPolicy, DiscardPolicy, DiscardOldestPolicy, and CallerRunsPolicy.

AbortPolicy – throws RejectedExecutionException.

DiscardPolicy – silently discards the new task.

DiscardOldestPolicy – discards the oldest queued task and enqueues the new one.

CallerRunsPolicy – the calling thread runs the task when the queue is full.

Given a scenario (core=5, max=10, queue=2, 20 tasks, default rejection policy), the candidate initially guesses the execution order but later writes a Java program to verify the behavior. The code creates a ThreadPoolExecutor with the specified parameters, submits 20 tasks, and prints active thread count and queue size.

public class IndexBinarySearch<T> {
    public static void main(String[] args) {
        ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(5, 10, 1, TimeUnit.MINUTES,
                new LinkedBlockingDeque<Runnable>(2));
        List<Runnable> rlist = new ArrayList<>();
        for (int i = 0; i < 20; i++) {
            rlist.add(new RunnableTest(poolExecutor));
        }
        for (int i = 0; i < 20; i++) {
            poolExecutor.execute(rlist.get(1));
        }
    }
}

class RunnableTest implements Runnable {
    ThreadPoolExecutor poolExecutor;
    public RunnableTest(ThreadPoolExecutor poolExecutor) {
        this.poolExecutor = poolExecutor;
    }
    @Override
    public void run() {
        int threadSize = this.poolExecutor.getActiveCount();
        int queueCurrentSize = this.poolExecutor.getQueue().size();
        System.out.println(Thread.currentThread().getName() + ": execution start: current threads:" + threadSize + " queue size:" + queueCurrentSize);
        try { Thread.sleep(1000); } catch (InterruptedException e) { e.printStackTrace(); }
    }
}

The execution result shows the first five tasks run immediately, the next two enter the queue, then new threads are created up to the maximum, and the remaining tasks are rejected. After some threads finish, queued tasks are processed.

Insight 3 Understanding the underlying principles enables you to apply a technology in varied scenarios.

Summary

When information is insufficient, seek comprehensive data through effective communication instead of guessing.

Classic algorithms, when applied flexibly, can solve most business problems.

Only by grasping the fundamentals can you adapt a technology to different contexts.