Java Concurrency Q&A: Akka, Locks, ThreadPoolExecutor, and More

Q1: Has Meituan used Akka internally? A: Used simple Akka, not Akka cluster; avoid blocking in actors, monitor mailbox length, avoid memory leaks by reusing actors or stopping them.

Q2: Is Java concurrency still needed in distributed microservices? A: Concurrency includes memory model, lock theory, lock‑free structures, and language concurrency models; understanding fundamentals influences system design beyond simple distributed locks.

Q3: When to choose ReentrantLock vs synchronized? A: Before Java 1.6, ReentrantLock for moderate concurrency; after 1.6, synchronized is heavily optimized, use ReentrantLock only for special features such as interruptible lock, tryLock, or fairness.

Q4: Queue rejection strategies? A: Reject newest (drop the latest request), reject oldest (drop the head), accept new requests, or random rejection depending on the queue type.

Q5: Core ideas of Java 8 ConcurrentHashMap: eliminated segment locks, uses CAS for lock‑free updates, hash‑algorithm optimization, extensive CAS‑based operations.

Q6: How to prepare for concurrency interview? A: Study four aspects – memory model and consistency, lock theory (spin, deadlock, livelock), lock‑free data structures, and each language’s concurrency model; focus on theory if the role requires deep concurrency knowledge.

Q7: Advice for Java beginners: read books (Core Java, Effective Java), learn J2EE, explore common open‑source projects, and follow technical blogs or newsletters.

Q8: When to use read‑write lock and Condition? A: Read‑write lock for read‑heavy scenarios; Condition for thread coordination when using ReentrantLock (instead of wait/notify with synchronized).

Q9: ThreadPoolExecutor internal mechanism: task submission flow (core threads, queue, max pool, rejection), rejection policies (Abort, CallerRuns, DiscardOldest, Discard), configuration guidelines for CPU‑bound vs I/O‑bound workloads, and monitoring metrics.

Q10: ReentrantLock Condition implementation and relation to AQS: Condition is built on AbstractQueuedSynchronizer, the core of many Java synchronizers, providing the blocking and signaling mechanisms.

Q11: Effective way to read source code: read documentation, understand the overall flow, and debug the code.

Q12: Why removing volatile may not show reordering issues? A: CPU architecture (e.g., Intel) often provides sufficient ordering, making volatile sometimes unnecessary in practice.

Q13: Backend measures to prevent overselling in flash‑sale scenarios: the answer indicates the question was unclear.