Java Programming Questions

Zero/minimal downtime migration strategy

1. Plan additive-only changes first (new columns, tables, indexes) so old and new code can run concurrently.
2. Use migration tools (Flyway/Liquibase) for versioned schema changes. For large ALTERs (drop column, change type), use online tools (gh-ost or pt-online-schema-change) to avoid locks.
3. Backfilling computed fields: add nullable column, deploy app code that writes to both old and new fields (dual-write), run an online backfill job that updates existing rows in small batches during low traffic.
4. Online backfills: implement id-range or time-window batched updates with throttling and monitoring; consider using distributed job workers.
5. Rolling out application changes:
   • Phase 1: deploy code that reads from old column and writes to both (backward-compatible).
   • Phase 2: run backfill until zero rows left needing migration.
   • Phase 3: deploy code that reads from new column (feature flag), then remove dual-write.
6. Safe rollback:
   • Keep old code path until new code verified.
   • For destructive operations, schedule maintenance window or use re-creation strategies.

Tools

• Flyway/Liquibase for schema versioning; gh-ost or pt-online-schema-change for online ALTER TABLE on MySQL. For Postgres, use pg_repack or native online-friendly ALTERs and logical replication for complex migrations.

Best practices

• Test migrations in staging with production-like data size.
• Monitor performance, locks, replication lag during migrations.
• Use feature flags to minimize blast radius and allow gradual rollout.

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.

Dependency Injection approaches in Spring

• Constructor injection: dependencies provided via constructor. Pros: immutable, explicit, best for testability, prevents partially constructed beans. Cons: verbose for many deps. Preferred.
• Setter injection: dependencies set via setters. Pros: optional deps, flexible. Cons: allows incomplete initialization, harder to enforce invariants.
• Field injection (@Autowired on fields): concise. Cons: hides dependencies, hard to unit-test without reflection, not suitable for final fields.

Pitfalls: circular dependencies cause failures at startup; use Provider/optional injection or redesign to remove cycle.

Example (constructor injection)

@Service
public class UserService {
  private final UserRepository repo;
  public UserService(UserRepository repo) { this.repo = repo; }
  public User getById(Long id) { return repo.findById(id).orElse(null); }
}

Constructor injection makes unit testing simple by passing a mock UserRepository.

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.