Java Programming Questions

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.

Primary key vs Unique constraint vs Foreign key

• Primary Key: Uniquely identifies rows, not null, usually clustered/indexed. Use case: id column for entity lookups. Performance: fast primary-key lookups; inserts/updates maintain index cost. JPA: @Id (often @GeneratedValue).

• Unique Constraint/Index: enforces uniqueness on column(s) but allows nulls (DB-dependent). Use case: email must be unique. Performance: supports fast equality lookups; adds overhead on writes. JPA: @Column(unique = true) or @UniqueConstraint on @Table, and @NaturalId in Hibernate.

• Foreign Key: enforces referential integrity between tables. Use case: order.customer_id references customers(id). Performance: adds checks on inserts/updates/deletes and may block cascading deletes; supports join optimizations when indexed. JPA: @ManyToOne with @JoinColumn; database-level FK is separate but generated by schema tools.

Trade-offs: more indexes = faster reads, slower writes. Use proper indexing and selectively enforce constraints where integrity matters.

Zero-downtime plan

1. Add nullable column with default NULL (fast metadata change).
2. Deploy app version that writes new column for new writes and reads fallback to computed value if NULL.
3. Backfill gradually with chunked updates: update WHERE new_col IS NULL ORDER BY pk LIMIT 10000 in small transactions, with sleep between chunks; run multiple workers coordinated to avoid hotspots.
4. Use online tools (pt-online-schema-change or native DB features) if DB supports fast backfill.
5. Once backfill reaches safe threshold, set column NOT NULL using CHECK constraint then ALTER to set NOT NULL (post-verify), or add computed persisted column if DB supports it.

Avoid big transactions

• Use idempotent chunk updates with small tx size; avoid full table rewrite.

App compatibility

• Use feature flag and versioned reads; app reads computed default when NULL until migration finalized.

Validation

• Compare sample rows before/after, spot-check counts of NULLs, run invariant queries, monitor replication lag, and ensure no long locks. Have rollback by stopping backfill and reverting app writes if issues arise.

Structured diagnostic approach

1. Observe metrics: latency, CPU, I/O, concurrent connections, locks (pg_stat_activity, pg_stat_io). Identify whether CPU, IO, or locks dominate.
2. Capture query plan: run EXPLAIN (ANALYZE, BUFFERS) for the slow JOIN to see join type, row estimates vs actual, and hotspots (e.g., nested loop reading many rows).
3. Check indexes & stats: ensure join keys are indexed (products.id, inventory.product_id); run ANALYZE if stats stale.
4. Inspect locks and waits: pg_locks, pg_stat_activity to see blocking queries causing serialization.
5. Check I/O: whether sequential scans read lots of pages; consider vmstat/iostat to see disk saturation.

Interpreting plans

• Nested Loop with large outer rows and expensive inner scans suggests missing indexes or bad join order.
• Hash join spilling to disk indicates memory insufficient.

Concrete fixes

• Add indexes on join/filter columns (inventory.product_id, products.id); consider covering indexes.
• Update statistics and consider increasing work_mem to avoid disk-spill for hash joins.
• Denormalize frequently-joined data into a single table or create a materialized view refreshed periodically for read-heavy APIs.
• For sub-ms response, move to read-optimized store (Elasticsearch) for search-heavy queries.
• If writes must be current, use incremental materialized view updates or maintain a cache.

Measure after each change; prefer non-disruptive index adds and config tuning before schema changes.

Requirements & constraints

• Strong consistency: updates visible immediately to subsequent reads across instances.
• Java/Spring Boot, relational DB, multi-instance.

Architecture recommendation

• Distributed cache (Redis) as single source for cached profiles to ensure coherence across instances.
• Use cache-aside pattern with atomic invalidation: write to DB inside tx, then invalidate or update cache atomically.

Invalidation/eviction strategy

• On read: try Redis; on miss, read DB and write-through to Redis with short TTL.
• On update: within DB transaction, update row, then publish a cache invalidation message (or update cache) after commit.

Atomic invalidation across instances

• Use DB transaction + outbox pattern: write update and an outbox row in same DB tx. A reliable publisher reads outbox and publishes an invalidation event to Redis pub/sub or a message broker.
• Consumers (app instances) subscribe and evict/update local caches upon event.

Multi-instance coherence

• Central Redis avoids split-brain; pub/sub ensures near-real-time invalidation.
• To avoid race (read-after-update) use read-after-write: client that performs update should update cache synchronously after commit (or include new value in response) so immediate reads see latest.

Trade-offs

• Distributed cache adds network latency but guarantees coherence; adds complexity (outbox, pub/sub). TTLs and eviction needed to bound memory.