Java Programming Questions

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.

Approach
Use per-user token buckets stored in a ConcurrentHashMap with bounded size (LRU eviction) and lock per-bucket using atomic CAS. Refill computed on access (lazy) using lastTimestamp.

import java.util.concurrent.*;
class TokenBucketRateLimiter {
  static class Bucket { double tokens; long lastRefill; }
  private final ConcurrentMap<String, Bucket> map = new ConcurrentHashMap<>();
  private final ScheduledExecutorService cleaner = Executors.newSingleThreadScheduledExecutor();
  private final double tokensPerSecond; private final double capacity; private final int maxEntries = 100_000;
  public TokenBucketRateLimiter(double tokensPerSecond, double capacity){ this.tokensPerSecond=tokensPerSecond; this.capacity=capacity; cleaner.scheduleAtFixedRate(this::evictIdle,60,60,TimeUnit.SECONDS);} 
  public boolean allowRequest(String userId){ long now=System.nanoTime(); Bucket b = map.computeIfAbsent(userId, k->{Bucket nb=new Bucket(); nb.tokens=capacity; nb.lastRefill=now; return nb;});
    synchronized(b){ double refill = (now - b.lastRefill)/1e9 * tokensPerSecond; b.tokens = Math.min(capacity, b.tokens + refill); b.lastRefill = now; if(b.tokens>=1){ b.tokens -=1; return true;} else return false; }
  }
  private void evictIdle(){ if(map.size()<=maxEntries) return; // simple eviction by scanning
    map.entrySet().removeIf(e->{ Bucket b=e.getValue(); return (System.nanoTime()-b.lastRefill) > TimeUnit.MINUTES.toNanos(10); }); }
}

Notes

• Thread-safety: per-bucket sync minimizes contention. computeIfAbsent is concurrent-safe.
• Memory-bounded: periodic eviction of idle buckets; maxEntries guard.
• For very high scale, replace map with Caffeine cache with expireAfterAccess and use per-entry locks or atomic state for better performance.

Requirements & constraints

• <5s freshness, minimal OLTP impact, high throughput, fault-tolerant.

High-level design

• CDC (Debezium) from DB → Kafka topics (per table/stream)
• Stream processing (Flink or Kafka Streams) for enrichment & aggregation
• Write aggregated/denormalized slices to read-optimized store (ClickHouse for OLAP or Elasticsearch for search)
• Dashboard reads the read store

Schema & aggregation

• Events: include event id, timestamp, partition key (user/product), version/seq
• Maintain pre-aggregated windows (1s, 1m) and rollups; use compacted topics for state checkpoints

Consistency & ordering

• Use Kafka partitions keyed by entity to preserve ordering; Flink stateful operators keyed by same key for correct aggregation.
• Tolerate eventual consistency; expose event time vs processing time; provide staleness metadata.

Backfill & reprocessing

• Use Kafka topic retention + snapshotting; or run CDC from historical export to re-populate aggregates; design idempotent processors and maintain offsets in durable store.

Fault tolerance

• Checkpointing (Flink) and Kafka consumer groups for replay; store state in durable state backend (RocksDB + S3 checkpointing).
• Use exactly-once semantics where possible (Kafka transactions, Flink two-phase commit to sinks like ClickHouse via idempotent writes).

Measuring lag & correctness

• Instrument pipeline lag: event ingestion timestamp vs write-to-store timestamp; emit metrics for 95/99 percentiles.
• Use canary streams with synthetic events to validate correctness end-to-end.
• Periodic reconciliations comparing aggregates from OLTP (slow) vs pipeline for drift detection.

This architecture achieves near-real-time dashboards with controlled consistency, replayable pipelines, and measurable correctness.

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.

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.