Wait, Notify(All)- check condition again after wake up and in a loop- while(condition is not true) obj.wait();- missed signals- spurious wakeups

Lock

- replaces synchronized

Condition

- suspend thread's execution, until the condition is true.

- a lock can have multiple (conditions) wait-sets per object

- replaces monitor methods

ReentrantLock- interruptible, timeout(tryAcquire)

Semaphore

- n permits, acquire, release

- Limiting concurrent access

CountDownLatch- countDown, await- can't reuse- work even if countDown is called before await (unlike wait, notify - missing notification)

CyclicBarrier- synchronize some tasks at a common point- reusableDouble-checked locking- check null again inside the critical blockVolatile- modification to the field is immediately seen by other threads- not cached in registers, force main memory access

- no reorder- happens-beforeany memory writes by one statement are visible to another statement.Use Volatile- When Writes Do Not Depend on Its Current Value- Use Volatile Fields for Reading and Locks for WritingImplementing CopyOnWriteArrayList- private transient volatile Object[] array;- Use lock in set(index, element)

Blocking QueueLinkedBlockingQueueArrayBlockingQueuePriorityBlockingQueueDelayQueueThreadPoolnewCachedThreadPool- Use SynchronousQueue, may use too many threadsnewFixedThreadPool, newSingleThreadExecutor- Use LinkedBlockingQueue, may use too much memory- Be cautious about unbounded resource - thread, memory

Always think about different approaches, think better approaches and say it.Step 1:Ask questions, don't assume (at lease check your assumption)- whether this is algorithm or design problem?Step 2: System interface definition- interface, main functionsStep 3: High level design with some diagramBack-of-the-envelope capacity estimationDefining the data modelIdentifying and resolving bottlenecksMake a List:- main functions of the system- locate bottleneck + how to scaleUnique challenges of these features/systemNon-function featuresUnique featuresRate limiter - scalable, availability, DDosPriority - Critical vs Non-CriticalLoad smoothy or spiky(predictable or not)?Use cases analysis- How client is going to use itLocate the problem of the current design - show you are aware of themHow to optimize it if possibleHow to scaleSeparate of concernsSeparate or notRate limiter - embedded in application or seperatedTiny url - separate write, read apiFollow the user case, end to endWhat's the bottleneck, the challengeHow to scaleHow to handle change - node added/removed/crashed

The features of these functions- read/write ratio, read heavy or write heavy or bothHow to use itSenarioBetter user experienceUser perceived experience/speed- cheat, approximateThinking from client/user perspectiveHow they use it, what they would like to knowExtra functions that may be related or neededAPI DesignIdempotencyIdempotency keyBack pressure exponential backoffRandomness, Jitter