JUC

Hardware foundations needed to understand the JMM: von Neumann architecture, caches, coherence, pipelines, reordering, memory barriers, and memory consistency models.

1. What it is. An implementation of pessimistic locking in Java. Compared with volatile, it is a heavyweight lock and can guarantee atomicity, ordering, and visibility. 2. When to use it. 3. How to use it. 4. Principle analysis of synchronized blocks. 5. Principle analysis of synchronized methods.

What volatile is, when it is more suitable than synchronized, an assembly experiment, and visibility/ordering analysis.

1. What it is. To understand CAS, first understand optimistic and pessimistic locking. 1.1. Optimistic vs. pessimistic locking. 1.2. CAS. 2. How to use it.

1. What it is. A queue synchronizer used to implement other concurrency utilities in JUC. 2. How to use it. 3. Principle analysis: queue structure, lock acquisition, enqueueing, parking, cancellation, interruption recovery, and lock release.

What ReentrantLock is, comparison with synchronized, implementation principle, and references.

1. What it is. Similar to Object.wait/notify with synchronized; Condition.await/signal work with Lock to implement conditional waiting and wake-up. 2. Usage. 3. Implementation principles: Condition queue, await, transfer to AQS queue, signalAll, and signal.

What CyclicBarrier is, usage with and without a barrier action, and source analysis based on Lock, Condition, generations, and await.

What CountDownLatch is, how to use it, comparison with CyclicBarrier, and its AQS-based countDown/await implementation.

1. What it is. This list adopts the idea of separating reads and writes (weak consistency): reads can proceed concurrently without locking; writes require locking, copying the original data, modifying the copy, and then writing it back to the list. 2. How to use it. 3. Principles. 3.1. Constructor. The underlying implementation uses an Object array and accesses it through getArray/setArray.

1. What it is. A copy-on-write set: ordered and without duplicates, implemented internally with CopyOnWriteArrayList. 2. How to use it. 3. Principle analysis. 3.1. Constructor. 3.1.1. The underlying implementation uses CopyOnWriteArrayList. 3.2. add method. 3.2.1. Delegates to CopyOnWriteArrayList.

What ArrayBlockingQueue is, how to use it, and source analysis of its array, lock, conditions, put/take/offer/poll/add/remove/element/peek methods.

What ThreadLocal is, how to use it, and source analysis of ThreadLocalMap, set/get/remove, open addressing, weak keys, and memory-leak concerns.

1. What it is. Java's thread-pool framework separates task submission from task execution. 1.1. Why thread pools are needed: reuse threads, because creating/destroying threads is expensive and too many threads cause excessive CPU context switching. 1.2. Use cases: individual tasks should not run too long, and there are many tasks.

1. What it is. Used for asynchronous programming. In Java, so-called asynchronous programming means putting blocking code into a separate thread for execution and notifying the main thread when a result is available. 2. Future vs CompletableFuture. 3. Usage. 4. Source-code analysis.

1. Constructor 2. put method 2.1. hash 2.2. ensureSegment 2.3. Segment.put 2.3.1. scanAndLockForPut 2.3.2. rehash 3. get 4. containsKey 5. remove 5.1. segmentForHash 5.2. Segment.remove

What fork/join is, why it exists, usage, and work stealing.

1. What it is. Used for exchanging data between two threads; data flows in both directions. 1.1. Exchanger vs. SynchronousQueue. 2. Usage. 3. Implementation analysis.

1. What ReentrantReadWriteLock is. 2. ReentrantReadWriteLock categories. 3. References.

1. What it is. A rate-limiting utility class that allows only n threads to access a resource at the same time. 2. Implementation analysis. 2.1. UML.

1. What it is. 2. How to verify that Java threads are kernel-level threads. 2.1. Before running. 2.2. After running.

What Unsafe is, how it relates to manual memory access, and examples of reading and atomically updating fields by memory offset.

After understanding the underlying computer architecture, revisit why the Java Memory Model is needed, what it defines, and happens-before.

1. JVM optimizations for locks: lock elimination, lock coarsening, biased locking, and adaptive locking. 2. Analysis of lock inflation. 3. Application-level optimization of lock usage. 4. Adjusting the number of spins.

Build a simple AQS-like lock by hand to better understand the real AQS source code: requirements, fields, blocking/waking, waiter queue, lock/unlock flow, fairness, final implementation, test, and flow.

A fair lock follows the first-come, first-served principle. Even after the lock has been released, a later-arriving thread cannot barge in; it must wait until nobody is ahead of it. 1. Usage. 2. Principle analysis.

1. What it is. A thread-safe blocking queue. Characteristics: FIFO; blocking insertion when the queue is full and blocking removal when the queue is empty; bounded or unbounded capacity; thread safety. 2. Use cases. Producer-consumer. 3. How to use it. 4. Detailed comparison of BlockingQueue implementations.

1. Usage 2. newCachedThreadPool 3. newScheduledThreadPool 4. newFixedThreadPool 5. newSingleThreadExecutor

1. What it is. A thread-safe HashMap implemented with synchronized + CAS + the HashMap structure (array + linked list + red-black tree). 2. How to use it. 3. Principle analysis: constructor, Node, put, initialization, insertion, resizing, get, remove, and containsKey.

1. Using BlockingQueue. 2. Using wait/notify. 3. Using Lock/Condition. Compared with wait/notify, two Conditions are used so producers and consumers are not woken together; each side wakes only the other side.

1. What it is. A nonfair read-write lock may let a newly arriving thread compete without strictly following queue order. 2. How to use it. 3. Source-code analysis: constructor, read locking/unlocking, write locking/unlocking, and AQS integration.

1. What it is. Rate limiting using a nonfair strategy. 2. Usage. 3. Principle analysis: constructor, NonfairSync, acquire, shared acquisition through AQS, nonfair acquisition, release, and shared release.

1. When a thread wakes after sleep. 2. Thread.sleep vs. Object.wait. 3. References.

A nonfair lock allows any arriving thread to compete for the lock once it has been released, regardless of arrival order. 1. Usage. 2. Implementation principles.

What LinkedBlockingQueue is, usage, and source analysis of its linked-list structure, separate put/take locks, conditions, and queue operations.

1. What is RejectedExecutionHandler? When corePoolSize is full, blockingQueue is full, and maxPoolSize is also full, how should a new task be handled? This is determined by RejectedExecutionHandler. 2. Types: CallerRunsPolicy, AbortPolicy, DiscardPolicy, DiscardOldestPolicy.

Example and status inspection.

1. What it is. A fair read-write lock follows queue order: if threads are already waiting ahead, the current thread should not barge in. 2. How to use it. 3. Source-code analysis: constructor, read locking/unlocking, write locking/unlocking, and AQS integration.

1. What it is. Rate limiting using a fair strategy. 2. Usage. 3. Principle analysis: constructor, FairSync, acquire, shared acquisition through AQS, fair acquisition, release, and shared release.

1. Thread state enum. 2. State transitions. 3. References.

What PriorityBlockingQueue is, binary-heap basics, usage, and source analysis of growth, offer/put, take, and heap adjustment.

1. What it is. A blocking queue implemented internally with a singly linked structure that does not store elements. A writer must have a reader at the same time in order to proceed, and vice versa; otherwise the writer or reader remains blocked. 2. Usage. 3. Principles. 3.1. Constructor. 3.1.1. Transfer. 3.1.2. QNode. 3.2. put blocking. 3.2.1. Calls TransferQueue.

1. What it is. Thread-safe atomic classes implemented with CAS. 2. Usage, using AtomicInteger as an example. 3. Principle analysis. 4. Problems with AtomicInteger: high CPU usage and the ABA problem, plus a version-number solution with AtomicStampedReference.

1. Estimate the number of threads 1.1. Throughput = concurrency / response time 1.2. TPS estimation 1.3. I/O-intensive or CPU-intensive 1.4. Dark Magic 2. References

Start three threads to calculate separately; use the final thread to aggregate the result.