Java Programming Questions

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.

Recommended indexes

1. On orders(user_id, total_amount, created_at DESC, id) — composite index to support WHERE user_id = ? AND total_amount > 100 and ORDER BY created_at DESC. Include id to avoid lookup.
2. On order_items(order_id) — index supports join; if often counting, use order_items(order_id) or a covering index (order_id) is fine.

Why they help

• Composite index narrows rows for the user and amount predicate and supplies ordering, allowing index-only or index scan followed by limited sort.
• order_items index speeds JOIN and GROUP BY aggregation.

Trade-offs

• Write amplification: composite indexes increase insert/update cost and storage.
• Storage: more disk used for indexes.

Other optimizations

• Denormalize item_count into orders and maintain via trigger or application logic for fast reads; reduces join and aggregation cost.
• Maintain a materialized view aggregated by order for heavy-read patterns.
• If counting is rare but acceptable slightly stale, cache counts or use async backfill.

Query rewrite

• Pre-aggregate: SELECT o., oi_count.item_count FROM orders o JOIN (SELECT order_id, COUNT() item_count FROM order_items GROUP BY order_id) oi_count ON oi_count.order_id=o.id WHERE ... LIMIT 50; with proper indexes this is faster.

Choose denormalization when read-latency is critical and write-frequency manageable.

Approach overview

1. Triage heap dump to identify leak source. 2) Reproduce locally with targeted load. 3) Remediate and add tests/CI checks.

Tools

• Capture: jmap (heap dump), jcmd GC.heap_info
• Analyze: Eclipse MAT, jhat, VisualVM
• Runtime: jcmd VM.native_memory, async-profiler

Investigation steps

• Open dump in MAT. Look at Dominator Tree and list org.example.cache.Cache$Node retained set.
• Inspect GC Roots and shortest reference chains to GC root to find why nodes are strongly reachable.
• Check incoming/outgoing references: static fields, ThreadLocal maps, live threads, listener lists.

Common patterns to check

• Static collections or caches without eviction
• ThreadLocal holding value per thread pool thread
• Unregistered listeners/callbacks or scheduled tasks
• Large object graph retained via single root (e.g., session map)

Reproduce locally

• Build a focused test that exercises caching behavior and runs under similar concurrency/sample data.
• Use stress test or unit test that runs until memory grows, capture periodic heap dumps.

Remediation

• Add eviction (LRU/TTL) or use Weak/SoftReferences where appropriate.
• Ensure listeners are removed on lifecycle stop; clear ThreadLocal in finally blocks; close scheduled tasks.
• Replace static caches with Cache implementations (Caffeine) with size/expire and metrics.

Prevention

• Add unit/integration memory tests (heap baseline after workload), leak-detector in CI (e.g., assert retained size below threshold), and CI job that runs short stress tests and compares heap usage.
• Instrument production with metrics (cache size, GC pause, native memory) and alerts.

This methodical pipeline ensures root cause discovery, safe remediation, and regression protection.

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.

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.