What is a Memory Leak in Java?

A memory leak happens when objects are no longer needed but still referenced, preventing the garbage collector from reclaiming their memory.
In Java, this usually doesn’t crash your program immediately but gradually consumes heap space → OutOfMemoryError.

In Spring Boot, memory leaks often occur due to:

• Long-lived objects holding references
• Caches, maps, lists growing indefinitely
• Static references
• Improperly scoped beans
• Threads/executors not shut down

 Symptoms of Memory Leaks

1. High heap usage in monitoring tools.
2. Frequent Full GC with little memory reclaimed.
3. Application slows down over time.
4. OutOfMemoryError eventually occurs.

 How to Track Memory Leaks in Java/Spring Boot

A. JVM Monitoring Tools

1. VisualVM
   • Comes with JDK (bin/jvisualvm)
   • Connect to running JVM → Monitor heap usage → Take heap dumps
2. JConsole
   • For basic monitoring of memory and threads
3. Java Flight Recorder / Mission Control
   • Built-in in JDK 11+
   • Records detailed memory, thread, and CPU usage

B. Profilers

• YourKit, JProfiler, Eclipse MAT
• They help identify:
  • Objects consuming most memory
  • Which objects are still strongly referenced
  • Growth patterns over time

C. Heap Dumps and Analysis

1. Trigger a heap dump when memory is high:

2. Analyze with Eclipse Memory Analyzer Tool (MAT)
   • Look for “Leak Suspects”
   • Identify objects that shouldn’t be retained
   • Trace back which code is holding references

D. Spring Boot-Specific Tips

1. Actuator Metrics
   • Add spring-boot-starter-actuator
   • Use /actuator/metrics/jvm.memory.used to monitor memory usage

2. Heap Dumps on OOM

   server:    tomcat:      max-threads: 200 spring:    jvm:      heap-dump-on-out-of-memory-error: true   
3. Check for common leak patterns:
   • Singleton beans holding large collections
   • Unbounded caches (Map, List)
   • ThreadLocal not cleaned up
   • Database connections not closed
   • @Scheduled tasks creating objects indefinitely

 How to Fix Memory Leaks

A. Code-Level Fixes

1. Avoid Static References
   • Don’t keep static Map or List if it grows over time.
2. Proper Bean Scoping
   • Use @Scope("prototype") for beans that should not live indefinitely

3. Clean Up ThreadLocals

   try {    ThreadLocal<MyObject> local = ...; } finally {    local.remove(); } 
4. Close Resources
   • Always close ResultSet, PreparedStatement, Connection
   • Use try-with-resources
5. Limit Caches
   • Use Guava Cache or Caffeine with eviction policies
6. Avoid Unnecessary Object Retention
   • Example: don’t store old DTOs in lists unless needed

B. Spring Boot & JVM Tuning

1. GC Tuning

   • Use G1GC or ZGC for large heaps
   • Example JVM option:
   -XX:+UseG1GC -Xmx2G -Xms1G 
2. Monitor and Adjust Thread Pools
   • Executors creating too many threads can retain memory
3. Profiling in Production
   • Use JFR or VisualVM snapshots
   • Detect memory leak patterns over time

C. Example: Common Leak in Spring Boot

 Fix:

 Practical Steps in Spring Boot App

1. Enable Actuator → Monitor /metrics for memory usage
2. Use heap dumps at regular intervals or on OOM
3. Analyze with Eclipse MAT → Find objects that are not garbage collected
4. Fix code → Limit caches, close resources, remove unused references
5. Retest and monitor memory over time

Using Abstract Classes and Interfaces in Real-World Software Design: A Payment Processing Use Case

In enterprise software development, one of the most common architectural debates is when to use abstract classes and when to use interfaces. While interfaces define a contract that classes must follow, abstract classes allow developers to share common code across related implementations. To understand this better, let’s explore a real-world product-level use case: building a Payment Processing Engine for a Payroll & Business Finance Management System.

Problem Statement

Our system needs to handle multiple payment modes: Cash, UPI, Bank Transfer, Credit Card, and future expansion like Crypto or PayPal. Each payment type must validate transaction details, execute the payment, rollback on failure, and optionally support refund and reconciliation. This is a perfect scenario for combining interfaces + abstract classes.

 Step 1: Defining Interfaces (Contracts)

 Step 2: Abstract Class for Common Logic

 Step 3: Concrete Implementations

 UPI Payment

 Bank Transfer Payment

 Step 4: Payment Service in Action

 Why Use Both Abstract Class and Interface?

• Interfaces → Define rules that all payment types must follow.
• Abstract Class → Provides shared logic (validation, base fields).
• Concrete Classes → Implement specific rules for each payment type.

This combination ensures scalability (easy to add new payment methods), maintainability (common code stays in one place), and compliance with SOLID principles (especially Open-Closed and Liskov Substitution).