Java Programming Questions

Testing strategy for Java DAO/Repository layer

• Unit tests (fast, isolated): Use JUnit + Mockito to mock JDBC/JPA dependencies. Assert that queries built, parameter bindings, and repository method logic behave correctly. Example: verify repository translates domain filters into correct CriteriaBuilder calls.

• Integration tests (DB-backed): Use JUnit + Testcontainers (Postgres/MySQL) or an embedded DB for simpler schemas. Run migrations, exercise real SQL, assert CRUD, transactions, and mappings. Example: save entity and query by indexed column returns expected row.

• Contract / migration tests: Run Flyway/Liquibase migrations against a test DB and assert schema version, presence of constraints, and that legacy queries still work. Use Testcontainers and DBUnit or SQL assertions.

Tooling: JUnit 5, Mockito, Spring Test, Testcontainers, Flyway/Liquibase, AssertJ.

Each type asserts: unit -> interaction and logic; integration -> persistence correctness; migration -> schema compatibility.

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.

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.

Diagnosis steps

• Enable GC logging (-Xlog:gc*), capture heap/GC metrics (G1 pause times, frequency) and thread stacks during pause.
• Correlate latency spikes with GC logs and CPU/memory/alloc rate metrics.
• Use jcmd/jmap/jfr to inspect heap usage, object allocation rates, and live set.

Tuning & config

• Right-size heap: avoid too small (frequent GCs) or too large (long pauses). Tune -Xms/-Xmx to match observed live set + headroom.
• G1 tuning: adjust MaxGCPauseMillis, initiateHeapOccupancyPercent to trigger concurrent cycles earlier, increase G1NewSizePercent for throughput.
• Consider ZGC or Shenandoah for lower pause goals if JVM/OS supported and production-tested; they have concurrent compaction with sub-ms pauses but require Java builds supporting them.

Validation

• Create staging workload mirroring production allocation patterns; measure latency, GC pause percentiles, and throughput before/after changes using JFR and GC logs.
• Gradual rollout in prod with canary instances, monitor p99 latency and GC pause stats.

Best practices

• Reduce allocation churn: reuse buffers, prefer primitive arrays, off-heap caches if needed. Monitor metaspace and GC ergonomics. Document changes and keep rollback plan.

Immediate mitigations

• Return to safe state: deploy previous release or disable offending feature via feature flag.
• Short-term traffic controls: scale replicas, apply rate-limits, route traffic to healthy zones.
• DB-level throttling: increase connection pool timeouts, reduce query concurrency, or apply statement_timeout.

Triage & root-cause steps

• Verify traces and identify slow SQL text and plan (capture full SQL with bind params).
• Run EXPLAIN (ANALYZE, BUFFERS) on production-like data to confirm sequential scan.
• Check recent changes: code, query text, ORMs, new indexes dropped, schema changes, pg_stat_statements.
• Inspect planner inputs: table statistics, recent VACUUM/ANALYZE, parameter changes (work_mem) or config flags.
• Reproduce with captured params on staging.

Safe rollback / hotfix

• If query change is in code: rollback deploy atomically.
• If stats or plan issue: run ANALYZE or CREATE necessary index; use CONCURRENTLY to avoid locks.
• Use partial rollout (canary) after fix.
• Ensure rollback plan tested and DB migrations reversible.

Postmortem outline

• Timeline, impact, root cause, detection method.
• Actionable items: automated detection alerts for query plan regressions, add tests for critical queries, require plan checks in deployment, schedule periodic ANALYZE, CI that runs EXPLAIN on sample datasets, runbooks for rollback.
• Owners, deadlines, verification steps and metrics to measure recurrence (99th latency, query duration percentiles).