Java Programming Questions

Step-by-step plan to find CPU hotspots with minimal impact

1. Monitor metrics: confirm high CPU via system and JVM metrics (process CPU, GC, threads).
2. Lightweight sampling: collect periodic jstack samples (thread dumps) to see hot threads; take several spaced dumps.
3. Use Java Flight Recorder (JFR) in production for low-overhead profiling (enable continuous or for short window). Analyze hotspots.
4. Use async-profiler (native) if allowed: capture flame graph (CPU) for a short period; it's very low overhead.
5. Interpret flame graphs: wide boxes = heavy methods; stack shows callers → follow hottest paths.
6. Correlate with application traces/logs to map endpoint/transactions to hotspots.

Reduction strategies

• Algorithmic: replace O(n^2) with O(n log n) algorithms, avoid repeated work.
• Caching: memoize expensive computations or DB results off hot path.
• Batch work / move off critical path: push heavy tasks to background jobs or worker queues.
• Reduce object allocation: reuse buffers, avoid boxing, reduce GC pressure.
• Database/IO: optimize queries, add indexes, or cache results.

Tools summary

• jstack for quick dumps, JFR for low-overhead continuous profiling, async-profiler for detailed flamegraphs, profilers like YourKit in staging.

synchronized vs volatile vs AtomicInteger

• synchronized: provides mutual exclusion and memory visibility. Guarantees atomicity for a block/method and that entering a synchronized block sees prior writes. Use when multiple operations must be atomic (e.g., check-then-act).
  Example: synchronizing updates to a List or performing composite updates on multiple fields.

• volatile: guarantees visibility and ordering for single reads/writes of a variable but not atomicity for compound ops. Use for flags or state switches.
  Example: a boolean shutdown flag read by multiple threads.

• AtomicInteger (java.util.concurrent.atomic): provides atomic operations (get, incrementAndGet, compareAndSet) and weaker locking overhead. Guarantees atomicity for its methods and volatile-like visibility.
  Example: high-throughput counters, sequence generators, or non-blocking algorithms.

Choose synchronized for compound critical sections, volatile for simple visibility, AtomicInteger for lock-free numeric updates.

Public API (example)

• V get(K key)
• void put(K key, V value, Duration ttl, Consumer<V> onEvict)
• void remove(K key)

Implementation outline

• Use ConcurrentHashMap<K, Node> for O(1) lookup.
• Maintain LRU order using a concurrent-friendly doubly-linked list or a striped LinkedHashMap; or better, use Caffeine which implements windowed LRU and is highly concurrent.
• Each Node holds value, expireAt, and references for eviction list. Use a background cleaner to remove expired entries and call eviction callback asynchronously.
• For thread-safety update operations: use CAS on Node references and small synchronized blocks only for list pointer updates or use lock-striping to reduce contention.

TTL & eviction callback

• On get, check expiry; if expired, remove and call callback.
• On put, if over capacity, evict least-recently-used node and trigger callback.

Correctness & tests

• Concurrency tests: many-thread get/put/remove verifying size bounds, no lost entries.
• Eviction tests: validate LRU order under access patterns.
• TTL tests: ensure entries expire roughly after TTL and callback invoked.

Recommendation

• Prefer Caffeine for production: offers O(1), TTL, eviction listeners, and proven concurrency and performance.

Transaction anomalies (brief)

• Dirty read: Tx A reads uncommitted writes of Tx B. Prevented by READ COMMITTED+.
• Non-repeatable read: A reads same row twice and sees different committed values.
• Phantom read: A re-executes a range query and sees newly inserted rows.
• Lost update: concurrent writes overwrite each other without awareness.
• Write skew: two concurrent transactions read overlapping data and write non-conflicting rows causing invariant break.

Bank transfer isolation strategy

• Prefer READ COMMITTED or REPEATABLE READ with explicit SELECT ... FOR UPDATE on account rows to avoid lost updates while keeping throughput.
• Application patterns:
  • Use SELECT FOR UPDATE to lock source and destination rows in a fixed order to avoid deadlocks.
  • Alternatively, optimistic locking with version column: read+check version then UPDATE ... WHERE version = ?; retry on mismatch.
  • Serializable isolation prevents anomalies but may increase serialization failures; use if invariants are complex.

Postgres vs MySQL

• Postgres: REPEATABLE READ implements true snapshot isolation; SERIALIZABLE provides predicate locking and higher safety. SELECT FOR UPDATE blocks and is reliable.
• MySQL InnoDB: REPEATABLE READ uses next-key locking; behavior differs: some phantom protection exists. MySQL's gap locks can block more, causing potential contention.
• Trade-offs: pessimistic locking (FOR UPDATE) is simpler and predictable with lower retry rates; optimistic locking scales better under low contention but requires retries. Choose based on expected concurrency and latency SLA.

Java memory model basics for backend engineers

• Heap vs Stack: local primitives and references live on thread stack; objects are allocated on the heap (shared). Stack frames are thread-local and short-lived.
• Young and Old generations: JVM divides heap—Young (eden + survivor) for new objects; survivors promoted to Old (tenured). Generational GC optimizes for short-lived objects.
• Full GC triggers: long-lived survivor promotion when Old gen is full, explicit System.gc(), or when CMS/G1 thresholds are exceeded; Full GC is expensive and pauses application.
• Common GC pressure patterns: creating many temporary objects (string concatenation in hot loops), loading large result sets into memory, returning large collections, or caching without eviction.

Best practices: reuse buffers (StringBuilder), stream results, page queries, and tune heap/gc ergonomics based on load.