From 5b88f1893d9e04778e1f3e05531c8e6f53169737 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Antonio=20Bre=C3=B1a=20Moral?= Date: Tue, 16 Sep 2025 20:09:35 +0200 Subject: [PATCH 1/2] Adding Tones in the Behaviours --- .cursor/rules/behaviour-consultative-interaction.md | 4 ++++ .cursor/rules/behaviour-progressive-learning.md | 4 ++++ .../resources/behaviour-consultative-interaction.xml | 2 ++ .../resources/behaviour-progressive-learning.xml | 4 ++++ .../src/main/resources/cursor-rules.xsl | 12 ++++++++++++ 5 files changed, 26 insertions(+) diff --git a/.cursor/rules/behaviour-consultative-interaction.md b/.cursor/rules/behaviour-consultative-interaction.md index f4c4d4f7..230edcda 100644 --- a/.cursor/rules/behaviour-consultative-interaction.md +++ b/.cursor/rules/behaviour-consultative-interaction.md @@ -8,6 +8,10 @@ version: 0.11.0-SNAPSHOT You are a Senior software engineer with extensive experience in Java software development +## Tone + +Treats the user as a knowledgeable partner in solving problems rather than prescribing one-size-fits-all solutions. Presents multiple approaches with clear trade-offs, asking for user input to understand context and constraints. Uses consultative language like "I found several options" and "Which approach fits your situation better?" Acknowledges that the user knows their business domain and team dynamics best, while providing technical expertise to inform decisions. + ## Goal This technique emphasizes **analyzing before acting** and **proposing options before implementing**. Instead of immediately making changes, the assistant: diff --git a/.cursor/rules/behaviour-progressive-learning.md b/.cursor/rules/behaviour-progressive-learning.md index 06523b45..f6812fb0 100644 --- a/.cursor/rules/behaviour-progressive-learning.md +++ b/.cursor/rules/behaviour-progressive-learning.md @@ -8,6 +8,10 @@ version: 0.11.0-SNAPSHOT You are a Senior software engineer with extensive experience in Java software development +## Tone + +Focuses on teaching principles and building deep understanding rather than just providing quick fixes. Explains the "why" behind every recommendation, connecting specific techniques to broader software engineering principles like SOLID, DRY, and YAGNI. Uses detailed examples with clear "good vs bad" comparisons. Encourages learning through progressive complexity - starting with fundamentals and building toward advanced patterns. Treats each interaction as a teaching opportunity to build long-term developer expertise. + ## Goal This behavior transforms **system prompts into structured learning experiences** that teach concepts progressively, building from fundamentals to advanced applications. Instead of just applying rules, the assistant: diff --git a/system-prompts-generator/src/main/resources/behaviour-consultative-interaction.xml b/system-prompts-generator/src/main/resources/behaviour-consultative-interaction.xml index a0eae009..0fbfafbb 100644 --- a/system-prompts-generator/src/main/resources/behaviour-consultative-interaction.xml +++ b/system-prompts-generator/src/main/resources/behaviour-consultative-interaction.xml @@ -9,6 +9,8 @@ You are a Senior software engineer with extensive experience in Java software development + Treats the user as a knowledgeable partner in solving problems rather than prescribing one-size-fits-all solutions. Presents multiple approaches with clear trade-offs, asking for user input to understand context and constraints. Uses consultative language like "I found several options" and "Which approach fits your situation better?" Acknowledges that the user knows their business domain and team dynamics best, while providing technical expertise to inform decisions. + This technique emphasizes **analyzing before acting** and **proposing options before implementing**. Instead of immediately making changes, the assistant: diff --git a/system-prompts-generator/src/main/resources/behaviour-progressive-learning.xml b/system-prompts-generator/src/main/resources/behaviour-progressive-learning.xml index e3e779b6..18d682d7 100644 --- a/system-prompts-generator/src/main/resources/behaviour-progressive-learning.xml +++ b/system-prompts-generator/src/main/resources/behaviour-progressive-learning.xml @@ -9,6 +9,10 @@ You are a Senior software engineer with extensive experience in Java software development + + Focuses on teaching principles and building deep understanding rather than just providing quick fixes. Explains the "why" behind every recommendation, connecting specific techniques to broader software engineering principles like SOLID, DRY, and YAGNI. Uses detailed examples with clear "good vs bad" comparisons. Encourages learning through progressive complexity - starting with fundamentals and building toward advanced patterns. Treats each interaction as a teaching opportunity to build long-term developer expertise. + + This behavior transforms **system prompts into structured learning experiences** that teach concepts progressively, building from fundamentals to advanced applications. Instead of just applying rules, the assistant: diff --git a/system-prompts-generator/src/main/resources/cursor-rules.xsl b/system-prompts-generator/src/main/resources/cursor-rules.xsl index 16fab380..d268d648 100644 --- a/system-prompts-generator/src/main/resources/cursor-rules.xsl +++ b/system-prompts-generator/src/main/resources/cursor-rules.xsl @@ -24,6 +24,8 @@ version: ## Role + + @@ -128,6 +130,16 @@ Description: + + +## Tone + + + + + From 5a57dd36da6864ed0d992deb28fef5ab58e40d2f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Antonio=20Bre=C3=B1a=20Moral?= Date: Wed, 17 Sep 2025 18:15:36 +0200 Subject: [PATCH 2/2] Adding a new course --- AGENTS.md | 2 +- docs/about.html | 1 + docs/archive.html | 1 + docs/blog/2025/prompt-quality-framework.html | 4 + docs/blog/2025/release-0.10.0.html | 4 + docs/blog/2025/release-0.8.0.html | 4 + docs/blog/2025/release-0.9.0.html | 4 + docs/courses/java-generics/faq.html | 2 +- docs/courses/java-generics/index.html | 1 + .../java-generics/module-1-foundations.html | 1 + .../java-generics/module-2-wildcards.html | 1 + .../java-generics/module-3-advanced.html | 1 + .../java-generics/module-4-realworld.html | 1 + .../java-generics/module-5-assessment.html | 1 + docs/courses/profile-memory-leak/index.html | 393 ++++++++++ .../module-1-foundations.html | 499 ++++++++++++ .../module-2-profiling.html | 640 ++++++++++++++++ .../module-3-analysis.html | 712 +++++++++++++++++ .../module-4-refactoring.html | 681 +++++++++++++++++ .../module-5-validation.html | 722 ++++++++++++++++++ docs/css/main.css | 3 + docs/feed.xml | 2 +- docs/index.html | 13 + docs/tags.html | 115 ++- docs/tags/advanced-patterns.html | 1 + docs/tags/analysis.html | 174 +++++ docs/tags/api-design.html | 1 + docs/tags/assessment.html | 1 + docs/tags/async-profiler.html | 203 +++++ docs/tags/before-after.html | 174 +++++ docs/tags/blog.html | 13 + docs/tags/comparison.html | 174 +++++ docs/tags/crtp.html | 1 + docs/tags/detection.html | 174 +++++ docs/tags/documentation.html | 174 +++++ docs/tags/evidence.html | 174 +++++ docs/tags/faq.html | 7 +- docs/tags/flamegraph.html | 173 +++++ docs/tags/foundations.html | 32 + docs/tags/generics.html | 7 +- docs/tags/help.html | 7 +- docs/tags/implementation.html | 174 +++++ docs/tags/java.html | 191 ++++- docs/tags/jmeter.html | 173 +++++ docs/tags/memory-leak.html | 327 ++++++++ docs/tags/pecs.html | 1 + docs/tags/performance.html | 31 + docs/tags/profiling.html | 327 ++++++++ docs/tags/real-world.html | 1 + docs/tags/records.html | 1 + docs/tags/refactoring.html | 174 +++++ docs/tags/sealed-types.html | 1 + docs/tags/self-bounded.html | 1 + docs/tags/serialization.html | 1 + docs/tags/setup.html | 174 +++++ docs/tags/support.html | 7 +- docs/tags/system-prompts.html | 173 +++++ docs/tags/type-erasure.html | 1 + docs/tags/type-safety.html | 1 + docs/tags/validation.html | 63 ++ docs/tags/variance.html | 1 + docs/tags/wildcards.html | 1 + .../README-DEV.md | 8 +- .../profiling-comparison-analysis-20250720.md | 8 +- .../docs/profiling-final-results-20250720.md | 14 +- .../profiling-problem-analysis-20250720.md | 6 +- .../docs/profiling-solutions-20250720.md | 14 +- .../docs/profiling-summary-20250720.md | 6 +- .../blog/2025/prompt-quality-framework.md | 1 + .../content/blog/2025/release-0.10.0.md | 1 + .../content/blog/2025/release-0.8.0.md | 1 + .../content/blog/2025/release-0.9.0.md | 1 + .../content/courses/java-generics/faq.md | 2 - .../courses/profile-memory-leak/index.md | 261 +++++++ .../module-1-foundations.md | 402 ++++++++++ .../profile-memory-leak/module-2-profiling.md | 573 ++++++++++++++ .../profile-memory-leak/module-3-analysis.md | 608 +++++++++++++++ .../module-4-refactoring.md | 597 +++++++++++++++ .../module-5-validation.md | 615 +++++++++++++++ site-generator/templates/maincss.ftl | 3 + site-generator/templates/nav.ftl | 1 + 81 files changed, 10169 insertions(+), 75 deletions(-) create mode 100644 docs/courses/profile-memory-leak/index.html create mode 100644 docs/courses/profile-memory-leak/module-1-foundations.html create mode 100644 docs/courses/profile-memory-leak/module-2-profiling.html create mode 100644 docs/courses/profile-memory-leak/module-3-analysis.html create mode 100644 docs/courses/profile-memory-leak/module-4-refactoring.html create mode 100644 docs/courses/profile-memory-leak/module-5-validation.html create mode 100644 docs/tags/analysis.html create mode 100644 docs/tags/async-profiler.html create mode 100644 docs/tags/before-after.html create mode 100644 docs/tags/comparison.html create mode 100644 docs/tags/detection.html create mode 100644 docs/tags/documentation.html create mode 100644 docs/tags/evidence.html create mode 100644 docs/tags/flamegraph.html create mode 100644 docs/tags/implementation.html create mode 100644 docs/tags/jmeter.html create mode 100644 docs/tags/memory-leak.html create mode 100644 docs/tags/profiling.html create mode 100644 docs/tags/refactoring.html create mode 100644 docs/tags/setup.html create mode 100644 docs/tags/system-prompts.html create mode 100644 site-generator/content/courses/profile-memory-leak/index.md create mode 100644 site-generator/content/courses/profile-memory-leak/module-1-foundations.md create mode 100644 site-generator/content/courses/profile-memory-leak/module-2-profiling.md create mode 100644 site-generator/content/courses/profile-memory-leak/module-3-analysis.md create mode 100644 site-generator/content/courses/profile-memory-leak/module-4-refactoring.md create mode 100644 site-generator/content/courses/profile-memory-leak/module-5-validation.md diff --git a/AGENTS.md b/AGENTS.md index 8e5f7bc9..0c704d48 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -7,7 +7,7 @@ A collection of `System prompts` for Java Enterprise development. ### Repository Layout ``` -java-cursor-rules/ +cursor-rules-java/ β”œβ”€β”€ .cursor/rules/ # 🎯 25 System prompts for Java Enterprise development (main output) β”œβ”€β”€ system-prompts-generator/ # πŸ—οΈ Java transformation engine (XML β†’ Markdown cursor rules) β”‚ β”œβ”€β”€ src/main/resources/ # XML rule definitions + XSLT stylesheets diff --git a/docs/about.html b/docs/about.html index a7c18c3b..4af34316 100644 --- a/docs/about.html +++ b/docs/about.html @@ -43,6 +43,7 @@ Courses
Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/archive.html b/docs/archive.html index bf704b53..24c9bfe2 100644 --- a/docs/archive.html +++ b/docs/archive.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/blog/2025/prompt-quality-framework.html b/docs/blog/2025/prompt-quality-framework.html index bd9bb33c..1915bfad 100644 --- a/docs/blog/2025/prompt-quality-framework.html +++ b/docs/blog/2025/prompt-quality-framework.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -70,6 +71,9 @@

    The Three-Node Quality Framework for AI Prompts

    2025-07-20 +   + + Juan Antonio BreΓ±a Moral   diff --git a/docs/blog/2025/release-0.10.0.html b/docs/blog/2025/release-0.10.0.html index 588fb18c..7c0a93bb 100644 --- a/docs/blog/2025/release-0.10.0.html +++ b/docs/blog/2025/release-0.10.0.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -70,6 +71,9 @@

    What's new in Cursor rules for Java 0.10.0?

    2025-09-05 +   + + Juan Antonio BreΓ±a Moral   diff --git a/docs/blog/2025/release-0.8.0.html b/docs/blog/2025/release-0.8.0.html index f77b5830..563dd1cd 100644 --- a/docs/blog/2025/release-0.8.0.html +++ b/docs/blog/2025/release-0.8.0.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -70,6 +71,9 @@

    What's new in Cursor rules for Java 0.8.0?

    2025-07-12 +   + + Juan Antonio BreΓ±a Moral   diff --git a/docs/blog/2025/release-0.9.0.html b/docs/blog/2025/release-0.9.0.html index 4b095c9a..c76c3076 100644 --- a/docs/blog/2025/release-0.9.0.html +++ b/docs/blog/2025/release-0.9.0.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -70,6 +71,9 @@

    What's new in Cursor rules for Java 0.9.0?

    2025-07-23 +   + + Juan Antonio BreΓ±a Moral   diff --git a/docs/courses/java-generics/faq.html b/docs/courses/java-generics/faq.html index e843cca8..bfff2921 100644 --- a/docs/courses/java-generics/faq.html +++ b/docs/courses/java-generics/faq.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -98,7 +99,6 @@

    Frequently Asked Questions - Java Generics Course

    -

    ❓ Frequently Asked Questions

    πŸ“š Course Content

    Q: What Java version do I need for this course?

    A: The course is designed for Java 17+ (LTS), but most concepts work from Java 8+. Modern features like Records and sealed types require Java 14+ and Java 17+ respectively.

    diff --git a/docs/courses/java-generics/index.html b/docs/courses/java-generics/index.html index a4608d02..9cc5958e 100644 --- a/docs/courses/java-generics/index.html +++ b/docs/courses/java-generics/index.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/courses/java-generics/module-1-foundations.html b/docs/courses/java-generics/module-1-foundations.html index 309f63d2..24d908a7 100644 --- a/docs/courses/java-generics/module-1-foundations.html +++ b/docs/courses/java-generics/module-1-foundations.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/courses/java-generics/module-2-wildcards.html b/docs/courses/java-generics/module-2-wildcards.html index 72bbf3a2..59eb7f7e 100644 --- a/docs/courses/java-generics/module-2-wildcards.html +++ b/docs/courses/java-generics/module-2-wildcards.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/courses/java-generics/module-3-advanced.html b/docs/courses/java-generics/module-3-advanced.html index 5b125cd3..2c9213ce 100644 --- a/docs/courses/java-generics/module-3-advanced.html +++ b/docs/courses/java-generics/module-3-advanced.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/courses/java-generics/module-4-realworld.html b/docs/courses/java-generics/module-4-realworld.html index 06c29579..d5e494eb 100644 --- a/docs/courses/java-generics/module-4-realworld.html +++ b/docs/courses/java-generics/module-4-realworld.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/courses/java-generics/module-5-assessment.html b/docs/courses/java-generics/module-5-assessment.html index 325a37e5..83bbdcab 100644 --- a/docs/courses/java-generics/module-5-assessment.html +++ b/docs/courses/java-generics/module-5-assessment.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/courses/profile-memory-leak/index.html b/docs/courses/profile-memory-leak/index.html new file mode 100644 index 00000000..00502b98 --- /dev/null +++ b/docs/courses/profile-memory-leak/index.html @@ -0,0 +1,393 @@ + + + + + + + + Mastering Java Memory Leak Detection - Complete Learning Path - Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    +
    +
    +
    +
    +

    Mastering Java Memory Leak Detection - Complete Learning Path

    +
    +
    +
    +
    +
    +
    + + +
    +
    +
    +
    + +
    + + 2025-09-17 +   + + Juan Antonio BreΓ±a Moral +   + + Version 0.11.0-SNAPSHOT +
    +   + + java + profiling + memory-leak + performance + system-prompts + async-profiler +
    +
    +
    + +

    🎯 Master Java memory leak detection through hands-on profiling with the Spring Boot memory leak demo

    +
    +

    πŸ“š Course Structure

    +
      +
    • Module 1: Foundations - 2 hours (Focus: Memory leak theory and setup; Key learning: Understanding leak patterns; profiling infrastructure)
      • +
    • Module 2: Profiling - 3 hours (Focus: Hands-on profiling mastery; Key learning: 21 profiling options; flamegraph interpretation)
      • +
    • Module 3: Analysis - 2 hours (Focus: Systematic analysis; Key learning: Evidence documentation; prioritization frameworks)
      • +
    • Module 4: Refactoring - 2 hours (Focus: Solution implementation; Key learning: Resource lifecycle patterns; coco=false fix)
      • +
    • Module 5: Validation - 1 hour (Focus: Before/after comparison; Key learning: Quantitative validation; success measurement)
      • +
    +

    Total Duration: 8-12 hours (depending on learning path)

    +

    Module 1: Memory Leak Foundations and Detection Setup (2 hours)

    +

    Learning Focus: Understanding memory leaks and setting up detection infrastructure

    +

    Key Topics:
    +- What are memory leaks and why they matter?
    +- Types of memory leaks in Java applications
    +- Introduction to the Spring Boot memory leak demo
    +- Setting up profiling infrastructure with system prompts
    +- Understanding the coco=true/false configuration pattern

    +

    Hands-on Activities:
    +- Explore the CocoController vs NoCocoController implementations
    +- Set up profiling scripts using @161-java-profiling-detect
    +- Run initial baseline profiling session

    +

    Learning Outcomes:
    +- Identify different types of memory leak patterns
    +- Set up automated profiling environment
    +- Understand the demo application architecture

    +
    +

    Module 2: Hands-on Profiling with System Prompts (3 hours)

    +

    Learning Focus: Using system prompts to systematically collect profiling data

    +

    Key Topics:
    +- Deep dive into @161-java-profiling-detect system prompt
    +- Interactive profiling script walkthrough (21 profiling options)
    +- Memory leak detection strategies (5-minute vs 30-second profiles)
    +- JMeter load testing integration for realistic scenarios
    +- Understanding flamegraph interpretation

    +

    Hands-on Activities:
    +- Execute memory allocation profiling (Option 2)
    +- Run memory leak detection workflow (Option 8)
    +- Generate JMeter load tests for consistent profiling conditions
    +- Create comprehensive memory analysis workflow (Option 9)

    +

    Learning Outcomes:
    +- Master the interactive profiling script
    +- Generate meaningful profiling data under load
    +- Interpret flamegraph visualizations effectively

    +
    +

    Module 3: Analysis and Evidence Collection (2 hours)

    +

    Learning Focus: Systematic analysis using @162-java-profiling-analyze

    +

    Key Topics:
    +- Systematic analysis framework for profiling data
    +- Problem categorization and severity assessment
    +- Evidence documentation with quantitative metrics
    +- Cross-correlation analysis techniques
    +- Impact vs Effort prioritization framework

    +

    Hands-on Activities:
    +- Analyze flamegraphs to identify memory leak patterns
    +- Create problem analysis documents following templates
    +- Develop prioritized solution recommendations
    +- Document evidence with specific file references

    +

    Learning Outcomes:
    +- Systematically analyze profiling results
    +- Create structured documentation for findings
    +- Prioritize fixes using Impact/Effort scoring

    +
    +

    Module 4: Refactoring and Solution Implementation (2 hours)

    +

    Learning Focus: Implementing fixes based on analysis findings

    +

    Key Topics:
    +- Understanding the coco=false refactoring strategy
    +- Thread pool lifecycle management
    +- Bounded collections implementation
    +- Resource cleanup patterns (@PreDestroy)
    +- Deployment verification procedures

    +

    Hands-on Activities:
    +- Switch from CocoController to NoCocoController
    +- Verify code changes are properly applied
    +- Implement monitoring and alerting
    +- Test application stability after refactoring

    +

    Learning Outcomes:
    +- Apply systematic refactoring strategies
    +- Implement proper resource management patterns
    +- Validate refactoring through testing

    +
    +

    Module 5: Validation and Comparison (1 hour)

    +

    Learning Focus: Using @164-java-profiling-compare to validate improvements

    +

    Key Topics:
    +- Before/after comparison methodology
    +- Quantitative metrics extraction
    +- Visual flamegraph comparison techniques
    +- Success criteria validation
    +- Documentation of improvements

    +

    Hands-on Activities:
    +- Generate post-refactoring profiling reports
    +- Perform side-by-side flamegraph comparison
    +- Create comparison analysis documentation
    +- Validate performance improvement targets

    +

    Learning Outcomes:
    +- Rigorously validate performance improvements
    +- Document quantified results
    +- Establish ongoing monitoring strategies

    +
    +

    πŸ› οΈ Tools and Technologies

    +

    Primary Tools:

    +
      +
    • async-profiler v4.1: Advanced profiling with flamegraph generation
      • +
    • JFR (Java Flight Recorder): Low-overhead continuous profiling
      • +
    • JMeter: Load testing for realistic profiling scenarios
      • +
    • Spring Boot Actuator: Application monitoring and health checks
      • +
    +

    System Prompts Used:

    +
      +
    • @161-java-profiling-detect: Setup and data collection
      • +
    • @162-java-profiling-analyze: Systematic analysis framework
      • +
    • @164-java-profiling-compare: Before/after validation
      • +
    • @151-java-performance-jmeter: Load testing integration
      • +
    +

    Visualization Techniques:

    +
      +
    • Flamegraphs: Call stack and allocation visualization
      • +
    • Heatmaps: Temporal analysis of performance hotspots
      • +
    • Memory usage charts: GC retention and heap growth patterns
      • +
    • Thread dumps: Concurrency and threading analysis
      • +
    +
    +

    πŸ› οΈ System Prompts Integration

    +

    This course demonstrates practical usage of three key system prompts:

    +

    @161-java-profiling-detect

    +

    Purpose: Data collection and problem identification
    +Usage: My Java application has performance issues - help me set up comprehensive profiling process using @161-java-profiling-detect and use the location examples/spring-boot-memory-leak-demo/profiler

    +

    @162-java-profiling-analyze

    +

    Purpose: Systematic analysis and solution development
    +Usage: Analyze the results located in examples/spring-boot-memory-leak-demo/profiler and use the cursor rule @162-java-profiling-analyze

    +

    @164-java-profiling-compare

    +

    Purpose: Before/after validation and improvement measurement
    +Usage: Review if the problems was solved with last refactoring using the reports located in @/results with the cursor rule @164-java-profiling-compare

    +
    +

    🎯 Key Concepts Covered

    +

    Memory Leak Patterns

    +
      +
    • βœ… Unbounded collection growth
      • +
    • βœ… Thread pool resource leaks
      • +
    • βœ… Missing lifecycle management
      • +
    • βœ… Cache leaks and retention issues
      • +
    +

    Profiling Techniques

    +
      +
    • βœ… async-profiler mastery (21 profiling options)
      • +
    • βœ… JFR analysis and interpretation
      • +
    • βœ… Flamegraph visual analysis
      • +
    • βœ… Load testing integration with JMeter
      • +
    +

    Enterprise Patterns

    +
      +
    • βœ… Bounded collections with graceful degradation
      • +
    • βœ… Shared resource management
      • +
    • βœ… @PreDestroy lifecycle patterns
      • +
    • βœ… Monitoring and alerting infrastructure
      • +
    +

    Analysis Methodologies

    +
      +
    • βœ… Problem-driven profiling strategies
      • +
    • βœ… Impact/Effort prioritization frameworks
      • +
    • βœ… Cross-correlation analysis techniques
      • +
    • βœ… Evidence-based documentation
      • +
    +
    +

    πŸ” Interactive Elements Throughout the Course

    +

    🧠 Knowledge Checks

    +
      +
    • "Before we continue, can you explain why GC retention grows with active memory leaks?"
      • +
    • "What would happen if we didn't implement @PreDestroy in our thread pools?"
      • +
    • "How do you interpret a flamegraph where the canvas height keeps growing?"
      • +
    +

    πŸ’‘ Learning Reinforcement

    +
      +
    • "Notice how the NoCocoController eliminates the memory leak - that's the power of proper resource lifecycle management!"
      • +
    • "This connects to our earlier lesson on bounded collections - remember the MAX_OBJECTS pattern?"
      • +
    • "The 318% memory retention increase we observed demonstrates why systematic profiling is critical!"
      • +
    +

    🎯 Practical Challenges

    +
      +
    • Implement custom bounded collections with error handling
      • +
    • Design monitoring strategies for production memory leak detection
      • +
    • Create custom profiling configurations for specific scenarios
      • +
    • Develop team knowledge transfer materials
      • +
    +
    +

    πŸ“Š Success Metrics and Validation

    +

    Technical Success Criteria

    +
      +
    • [ ] Memory leaks successfully detected and resolved
      • +
    • [ ] Quantified performance improvements documented
      • +
    • [ ] Systematic profiling workflow mastered
      • +
    • [ ] Production-ready monitoring strategy developed
      • +
    +

    Learning Validation Methods

    +
      +
    • [ ] Hands-on exercises completed successfully
      • +
    • [ ] Profiling reports generated and analyzed
      • +
    • [ ] Documentation created following professional templates
      • +
    • [ ] Knowledge check questions answered correctly
      • +
    +

    Real-World Application

    +
      +
    • [ ] Techniques applied to actual production applications
      • +
    • [ ] Team knowledge sharing sessions conducted
      • +
    • [ ] Performance monitoring integrated into CI/CD pipeline
      • +
    • [ ] Continuous improvement processes established
      • +
    +
    +

    πŸŽ“ Course Philosophy

    +

    Progressive Learning Design

    +

    This course follows the @behaviour-progressive-learning pattern:
    +- Extract core concepts from system prompts
    +- Structure content into progressive learning modules
    +- Create interactive exercises with guided solutions
    +- Generate comprehensive courses with multiple paths
    +- Provide assessments and validation checkpoints

    +
    +

    "The best time to learn performance optimization was yesterday. The second best time is now."

    +

    Happy profiling! Go to the foundations πŸš€

    + + +
    +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/courses/profile-memory-leak/module-1-foundations.html b/docs/courses/profile-memory-leak/module-1-foundations.html new file mode 100644 index 00000000..acf99dd2 --- /dev/null +++ b/docs/courses/profile-memory-leak/module-1-foundations.html @@ -0,0 +1,499 @@ + + + + + + + + Module 1: Memory Leak Foundations and Detection Setup - Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    +
    +
    +
    +
    +

    Module 1: Memory Leak Foundations and Detection Setup

    +
    +
    +
    +
    +
    +
    + + +
    +
    +
    +
    + +
    + + 2025-09-17 +   + + Juan Antonio BreΓ±a Moral +   + + Version 0.11.0-SNAPSHOT +
    +   + + java + profiling + memory-leak + foundations + detection + setup +
    +
    +
    + +

    Understanding Memory Leaks and Building Detection Infrastructure

    +

    ⏱️ Duration: 2 hours
    +🎯 Learning Objectives:
    +- Understand what memory leaks are and why they're critical in Java applications
    +- Identify different types of memory leak patterns in enterprise applications
    +- Explore the Spring Boot memory leak demo architecture
    +- Set up automated profiling infrastructure using system prompts
    +- Understand the coco=true/false configuration pattern for controlled testing

    +
    +

    🧠 Conceptual Foundation

    +

    What Are Memory Leaks in Java?

    +

    Definition: A memory leak in Java occurs when objects that are no longer needed by the application remain referenced and cannot be garbage collected, leading to gradual memory exhaustion.

    +

    πŸ” Key Insight: Unlike languages with manual memory management (C/C++), Java memory leaks are typically caused by logical errors where references to unused objects are unintentionally retained.

    +

    Types of Memory Leaks in Java Applications

    +

    1. Collection Leaks

    +
    // BAD: Unbounded growth
+private final List<RequestData> requests = new ArrayList<>();
+
+public void processRequest(RequestData data) {
+    requests.add(data); // Never removed!
+}
+
    +

    2. Thread Pool Leaks

    +
    // BAD: ExecutorService never shutdown
+public void createTask() {
+    ExecutorService executor = Executors.newFixedThreadPool(10);
+    executor.submit(() -> doWork());
+    // Missing: executor.shutdown()!
+}
+
    +

    3. Listener/Callback Leaks

    +
    // BAD: Listeners never removed
+public void addListener(EventListener listener) {
+    eventListeners.add(listener); // Accumulates forever
+}
+
    +

    4. Cache Leaks

    +
    // BAD: No eviction policy
+private final Map<String, ExpensiveObject> cache = new HashMap<>();
+
+public ExpensiveObject get(String key) {
+    return cache.computeIfAbsent(key, k -> new ExpensiveObject(k));
+    // Cache grows indefinitely!
+}
+
    +

    πŸ’‘ Learning Reinforcement

    +

    Notice how each leak type involves the same pattern: objects being added to collections or caches without corresponding removal logic. This is why systematic profiling is essential - these patterns are often subtle and hard to spot in code reviews!

    +
    +

    πŸ—οΈ Demo Application Architecture

    +

    Understanding the Spring Boot Memory Leak Demo

    +

    The spring-boot-memory-leak-demo project demonstrates controlled memory leak scenarios through two contrasting controller implementations:

    +

    CocoController (coco=true) - The Problematic Implementation

    +
    @RestController
+@RequestMapping("/api/v1")
+@ConditionalOnProperty(name = "coco", havingValue = "true", matchIfMissing = true)
+public class CocoController {
+
+    // LEAK 1: Unbounded list growth
+    private final List<MyPojo> objects = new ArrayList<>();
+
+    // LEAK 2: Thread pools created without cleanup
+    @PostMapping("/threads/create")
+    public ResponseEntity<String> createThread() {
+        ExecutorService executor = Executors.newFixedThreadPool(5);
+        // Missing shutdown logic!
+        return ResponseEntity.ok("Thread created");
+    }
+
+    // LEAK 3: Unbounded object accumulation
+    @PostMapping("/objects/create")
+    public ResponseEntity<String> createObject() {
+        objects.add(new MyPojo(/* large data */));
+        return ResponseEntity.ok("Object created: " + objects.size());
+    }
+}
+
    +

    NoCocoController (coco=false) - The Fixed Implementation

    +
    @RestController
+@RequestMapping("/api/v1")
+@ConditionalOnProperty(name = "coco", havingValue = "false")
+public class NoCocoController {
+
+    private static final int MAX_OBJECTS = 10000; // Bounded!
+    private final List<MyPojo> objects = Collections.synchronizedList(new ArrayList<>());
+
+    // Shared, managed thread pool
+    private final ExecutorService sharedExecutorService =
+        Executors.newFixedThreadPool(10, new CustomizableThreadFactory("shared-pool-"));
+
+    @PostMapping("/objects/create")
+    public ResponseEntity<String> createObject() {
+        // Bounds checking prevents unbounded growth
+        if (objects.size() >= MAX_OBJECTS) {
+            return ResponseEntity.badRequest()
+                .body("Maximum objects limit reached: " + MAX_OBJECTS);
+        }
+        objects.add(new MyPojo(/* same data */));
+        return ResponseEntity.ok("Object created: " + objects.size());
+    }
+
+    // Proper resource cleanup
+    @PreDestroy
+    public void cleanup() throws InterruptedException {
+        sharedExecutorService.shutdown();
+        if (!sharedExecutorService.awaitTermination(30, TimeUnit.SECONDS)) {
+            sharedExecutorService.shutdownNow();
+        }
+    }
+}
+
    +

    πŸ” Knowledge Check

    +

    Before we continue, can you identify the three main differences between these implementations that prevent memory leaks?

    +
    +Click to reveal answers +
      +
    1. Bounded Collections: MAX_OBJECTS constant prevents unbounded list growth
      2. +
    2. Shared Thread Pools: Single managed ExecutorService instead of creating new ones
      3. +
    3. Resource Cleanup: @PreDestroy method ensures proper shutdown of thread pools
      4. +
    +
    +
    +

    πŸ› οΈ Setting Up Profiling Infrastructure

    +

    Step 1: Understanding the Configuration Pattern

    +

    The demo uses Spring Boot's @ConditionalOnProperty to switch between implementations:

    +
    # application.properties (default - enables memory leaks)
+coco=true
+
+# application-vt.properties (virtual threads profile - fixes leaks)
+coco=false
+
    +

    πŸ’‘ Learning Insight: This pattern allows us to test the exact same endpoints with different implementations, providing perfect before/after comparison scenarios for profiling!

    +

    Step 2: Setting Up Detection Scripts using @161-java-profiling-detect

    +

    Let's set up the profiling infrastructure using the system prompt:

    +

    🎯 Practical Exercise 1: Initial Setup

    +
      +
    1. Navigate to the demo project:
      2. +
    +
    cd ./cursor-rules-java/examples/spring-boot-memory-leak-demo
+
    +
      +
    1. Verify the project structure:
      2. +
    +
    ls -la
+# You should see: run-java-process-for-profiling.sh, profiler/ directory
+
    +
      +
    1. Check existing profiling setup:
      2. +
    +
    ls -la profiler/
+# Expected: scripts/, results/, docs/ directories
+
    +

    🎯 Practical Exercise 2: Baseline Application Startup

    +
      +
    1. Start the application with memory leaks enabled (default):
      2. +
    +
    ./run-java-process-for-profiling.sh --help
+
    +
      +
    1. Verify the application is running:
      2. +
    +
    # In another terminal
+curl http://localhost:8080/actuator/health
+curl http://localhost:8080/swagger-ui/index.html
+
    +
      +
    1. Check which controller is active:
      2. +
    +
    curl -X POST http://localhost:8080/api/v1/objects/create
+# Should respond with "Object created: 1"
+
    +

    🎯 Practical Exercise 3: Initial Profiling Run

    +
      +
    1. Execute the profiling script:
      2. +
    +
    cd profiler/scripts
+./profile-java-process.sh --help
+
    +
      +
    1. Follow the interactive prompts:
      2. +
    +
      +
    • Problem Category: Select "2) Memory-Related Problems"
      • +
    • Process Selection: Choose your Spring Boot application
      • +
    • Profiling Option: Select "8. Memory Leak Detection (5min)"
      • +
    +
      +
    1. Generate load while profiling:
      2. +
    +
    # In another terminal, create load
+for i in {1..50}; do
+  curl -X POST http://localhost:8080/api/v1/objects/create
+  curl -X POST http://localhost:8080/api/v1/threads/create
+  sleep 2
+done
+
    +
      +
    1. Wait for profiling to complete and examine results:
      2. +
    +
    ls -la profiler/results/
+# Look for: memory-leak-*.html files
+
    +

    πŸ” Understanding Your First Profiling Results

    +

    Open the generated flamegraph in your browser:

    +
    # macOS
+open profiler/results/memory-leak-*.html
+
+# Linux
+xdg-open profiler/results/memory-leak-*.html
+
    +

    What to look for in the flamegraph:
    +- Canvas Height: Tall canvas indicates many allocation paths
    +- Wide Sections: Methods consuming significant memory
    +- Stack Depth: Deep call stacks may indicate inefficient patterns
    +- Color Patterns: Different colors represent different allocation types

    +

    πŸ’‘ Learning Reinforcement

    +

    This flamegraph represents the "before" state with active memory leaks. Notice the patterns - we'll compare this exact visualization after implementing fixes in later modules!

    +
    +

    πŸ“Š Baseline Metrics Collection

    +

    Establishing Performance Baselines

    +

    Before we can measure improvements, we need to establish baseline metrics:

    +

    🎯 Practical Exercise 4: Comprehensive Baseline Collection

    +
      +
    1. Generate comprehensive baseline data:
      2. +
    +
    cd profiler/scripts
+./profile-java-process.sh
+
    +
      +
    1. Select Option 9: Complete Memory Analysis Workflow
      2. +
    +
      +
    • This will generate three reports: +
        +
      • 30-second baseline
        • +
      • 60-second detailed analysis
        • +
      • 5-minute leak detection
        • +
      +
      • +
    +
      +
    1. Create sustained load for realistic metrics:
      2. +
    +
    # Run this in background while profiling
+./run-jmeter.sh --help
+./run-jmeter.sh -t 300 -c 5  # 5 minutes, 5 concurrent users
+
    +
      +
    1. Document your baseline results:
      2. +
    +
    ls -la profiler/results/ | grep $(date +%Y%m%d)
+# Record the file names and sizes for later comparison
+
    +

    Understanding JMeter Integration

    +

    The demo includes JMeter integration for consistent load testing:

    +
    # View the JMeter test plan
+cat src/test/resources/jmeter/load-test.jmx
+
    +

    Key JMeter Test Scenarios:
    +- Object Creation Load: Repeatedly calls /api/v1/objects/create
    +- Thread Creation Load: Repeatedly calls /api/v1/threads/create
    +- Mixed Workload: Combines both endpoints with realistic timing

    +

    πŸ” Knowledge Check

    +

    Why is consistent load testing crucial for memory leak detection?

    +
    +Click to reveal answer +

    Memory leaks are often only visible under sustained load because:
    +1. Accumulation Effect: Leaks compound over time
    +2. GC Masking: Small leaks may be hidden by normal GC cycles
    +3. Real-world Simulation: Production applications experience continuous load
    +4. Comparative Analysis: Consistent load enables accurate before/after comparisons

    +
    +
    +

    🎯 Module 1 Assessment

    +

    Hands-on Validation Checklist

    +

    βœ… Conceptual Understanding:
    +- [ ] Can explain what causes memory leaks in Java applications
    +- [ ] Identified the three main leak patterns in CocoController
    +- [ ] Understands the coco=true/false configuration pattern

    +

    βœ… Technical Setup:
    +- [ ] Successfully started the Spring Boot application
    +- [ ] Generated initial profiling reports
    +- [ ] Created baseline flamegraph visualizations
    +- [ ] Executed JMeter load testing

    +

    βœ… Analysis Skills:
    +- [ ] Can interpret basic flamegraph patterns
    +- [ ] Documented baseline metrics for later comparison
    +- [ ] Understands the relationship between load testing and profiling

    +

    🎯 Practical Challenge

    +

    Challenge: Custom Load Pattern
    +Create a custom load testing script that exercises both problematic endpoints in a pattern that maximizes memory leak detection:

    +
    # Create your custom load script
+cat > custom-load-test.sh << 'EOF'
+#!/bin/bash
+echo "Starting custom memory leak load test..."
+
+# Your implementation here:
+# 1. Create objects in bursts
+# 2. Create threads periodically
+# 3. Monitor memory growth
+# 4. Report progress
+
+EOF
+chmod +x custom-load-test.sh
+
    +

    Success Criteria:
    +- Script runs for at least 5 minutes
    +- Generates measurable memory growth
    +- Provides progress feedback
    +- Creates reproducible load patterns

    +
    +

    πŸš€ Transition to Module 2

    +

    Congratulations! You've successfully:
    +- βœ… Understood the theoretical foundation of Java memory leaks
    +- βœ… Explored the demo application architecture
    +- βœ… Set up automated profiling infrastructure
    +- βœ… Generated baseline profiling data
    +- βœ… Established consistent load testing patterns

    +

    What's Next?

    +

    In Module 2: Hands-on Profiling with System Prompts, we'll dive deep into:
    +- Master all 21 profiling options in the interactive script
    +- Learn advanced flamegraph interpretation techniques
    +- Understand different profiling strategies for different problem types
    +- Generate comprehensive evidence for systematic analysis

    +

    πŸ’‘ Key Takeaway

    +

    "The foundation of effective performance optimization is systematic measurement. You've now built the infrastructure to measure, analyze, and validate performance improvements scientifically!"

    +

    Ready to dive deeper into profiling techniques? Let's continue to Module 2! 🎯

    + + +
    +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/courses/profile-memory-leak/module-2-profiling.html b/docs/courses/profile-memory-leak/module-2-profiling.html new file mode 100644 index 00000000..18c32d92 --- /dev/null +++ b/docs/courses/profile-memory-leak/module-2-profiling.html @@ -0,0 +1,640 @@ + + + + + + + + Module 2: Hands-on Profiling with System Prompts - Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    +
    +
    +
    +
    +

    Module 2: Hands-on Profiling with System Prompts

    +
    +
    +
    +
    +
    +
    + + +
    +
    +
    +
    + +
    + + 2025-09-17 +   + + Juan Antonio BreΓ±a Moral +   + + Version 0.11.0-SNAPSHOT +
    +   + + java + profiling + memory-leak + async-profiler + flamegraph + jmeter +
    +
    +
    + +

    Mastering the Interactive Profiling Script and Evidence Collection

    +

    ⏱️ Duration: 3 hours
    +🎯 Learning Objectives:
    +- Master the @161-java-profiling-detect system prompt and its 21 profiling options
    +- Learn problem-driven profiling strategies for different performance issues
    +- Understand flamegraph interpretation and visual analysis techniques
    +- Generate comprehensive profiling evidence under realistic load conditions
    +- Integrate JMeter load testing for consistent profiling scenarios

    +
    +

    🎯 Deep Dive: The Interactive Profiling Script

    +

    Understanding the Problem-Driven Approach

    +

    The profiling script in @161-java-profiling-detect follows a problem-first methodology:

    +
      +
    1. Problem Identification β†’ 2. Tool Selection β†’ 3. Data Collection β†’ 4. Evidence Generation
      2. +
    +

    This approach ensures you collect the right data for the specific problem you're investigating.

    +

    πŸ” The 5 Problem Categories

    +
    ./profiler/scripts/profile-java-process.sh
+# Step 0: Problem Identification
+
    +
      +
    • Performance Bottlenecks (Focus: CPU hotspots, inefficient algorithms; Recommended tools: CPU profiling, Wall-clock; Memory leak relevance: Medium - may indicate leak symptoms)
      • +
    • Memory-Related Problems (Focus: Memory leaks, heap usage, retention; Recommended tools: Memory allocation, Leak detection; Memory leak relevance: HIGH - Primary focus)
      • +
    • Concurrency/Threading (Focus: Lock contention, thread pools; Recommended tools: Lock profiling, Thread dumps; Memory leak relevance: High - thread pool leaks)
      • +
    • Garbage Collection (Focus: GC pressure, long pauses; Recommended tools: GC logs, Allocation profiling; Memory leak relevance: High - GC symptoms of leaks)
      • +
    • I/O and Network (Focus: Blocking operations, connection leaks; Recommended tools: Wall-clock, I/O analysis; Memory leak relevance: Medium - connection pool leaks)
      • +
    +

    πŸ’‘ Learning Insight

    +

    For memory leak detection, we primarily focus on Category 2 (Memory-Related Problems), but Categories 3 and 4 provide crucial supporting evidence!

    +
    +

    πŸ› οΈ The 21 Profiling Options Masterclass

    +

    Category A: Essential Memory Leak Detection Tools

    +

    🎯 Option 2: Memory Allocation Profiling (30s)

    +

    When to use: Initial memory pattern analysis
    +What it shows: Which methods allocate the most objects

    +
    ./profile-java-process.sh
+# Select: 2. Memory Allocation Profiling (30s)
+
    +

    🎯 Practical Exercise 1: Basic Allocation Analysis

    +
      +
    1. Start profiling with active memory leaks:
      2. +
    +
    # Ensure coco=true (memory leaks enabled)
+curl http://localhost:8080/actuator/env/coco
+
    +
      +
    1. Generate consistent load during profiling:
      2. +
    +
    # In separate terminal - run this DURING profiling
+for i in {1..100}; do
+  curl -X POST http://localhost:8080/api/v1/objects/create
+  sleep 0.5
+done
+
    +
      +
    1. Analyze the resulting flamegraph:
      2. +
    +
      +
    • Look for: Wide sections in CocoController.createObject
      • +
    • Measure: Canvas height and stack complexity
      • +
    • Document: Specific allocation patterns
      • +
    +

    Expected Results:

    +
    File: allocation-flamegraph-YYYYMMDD-HHMMSS.html
+Key Indicators:
+- CocoController.createObject shows significant width
+- MyPojo allocation patterns clearly visible
+- ArrayList.add operations consume memory
+
    +

    🎯 Option 8: Memory Leak Detection (5min)

    +

    When to use: Comprehensive leak pattern analysis
    +What it shows: Long-term memory accumulation patterns

    +
    ./profile-java-process.sh
+# Select: 8. Memory Leak Detection (5min)
+
    +

    🎯 Practical Exercise 2: Long-term Leak Detection

    +
      +
    1. Start the 5-minute leak detection:
      2. +
    +
    # This is a long-running profiling session
+./profile-java-process.sh
+# Select option 8
+
    +
      +
    1. Create sustained, realistic load:
      2. +
    +
    # Use JMeter for consistent 5-minute load
+./run-jmeter.sh -t 300 -c 3  # 5 minutes, 3 concurrent users
+
    +
      +
    1. Monitor progress and system behavior:
      2. +
    +
    # In another terminal, monitor memory usage
+watch -n 10 'curl -s http://localhost:8080/actuator/metrics/jvm.memory.used'
+
    +

    Expected Results:

    +
    File: memory-leak-YYYYMMDD-HHMMSS.html
+Key Indicators:
+- Continuous memory growth patterns
+- GC retention increasing over time
+- Object accumulation in specific methods
+
    +

    🎯 Option 9: Complete Memory Analysis Workflow

    +

    When to use: Comprehensive memory investigation
    +What it shows: Multi-phase analysis with baseline, detailed, and leak detection

    +
    ./profile-java-process.sh
+# Select: 9. Complete Memory Analysis Workflow
+
    +

    This option generates three sequential reports:
    +1. 30s Baseline: Quick memory allocation snapshot
    +2. 60s Detailed: In-depth heap analysis
    +3. 5min Leak Detection: Long-term accumulation patterns

    +

    🎯 Practical Exercise 3: Complete Workflow Analysis

    +
      +
    1. Execute the complete workflow:
      2. +
    +
    # This will take about 6.5 minutes total
+./profile-java-process.sh
+# Select option 9
+
    +
      +
    1. Coordinate load testing across all phases:
      2. +
    +
    # Create a script that matches the profiling phases
+cat > coordinated-load.sh << 'EOF'
+#!/bin/bash
+echo "Phase 1: Baseline load (30s)"
+timeout 30s bash -c 'while true; do curl -X POST http://localhost:8080/api/v1/objects/create; sleep 1; done' &
+
+echo "Phase 2: Detailed analysis load (60s)"
+sleep 30
+timeout 60s bash -c 'while true; do curl -X POST http://localhost:8080/api/v1/objects/create; curl -X POST http://localhost:8080/api/v1/threads/create; sleep 0.5; done' &
+
+echo "Phase 3: Leak detection load (5min)"
+sleep 90
+timeout 300s bash -c 'while true; do curl -X POST http://localhost:8080/api/v1/objects/create; sleep 0.3; done' &
+
+wait
+echo "All load phases completed"
+EOF
+chmod +x coordinated-load.sh
+
    +
      +
    1. Execute coordinated load:
      2. +
    +
    ./coordinated-load.sh
+
    +

    Expected Results:

    +
    Files generated:
+- memory-baseline-YYYYMMDD-HHMMSS.html (30s snapshot)
+- heap-analysis-YYYYMMDD-HHMMSS.html (60s detailed)
+- memory-leak-complete-YYYYMMDD-HHMMSS.html (5min comprehensive)
+
    +

    Category B: Advanced Profiling Techniques

    +

    🎯 Option 12: All Events Profiling (30s)

    +

    When to use: Comprehensive system analysis
    +What it shows: CPU, allocation, lock, and wall-clock data simultaneously

    +
    ./profile-java-process.sh
+# Select: 12. All Events Profiling (30s)
+
    +

    Expected Results:

    +
    Files generated:
+- all-events-YYYYMMDD-HHMMSS.jfr (JFR recording)
+- all-events-YYYYMMDD-HHMMSS.html (Converted flamegraph)
+
    +

    🎯 Option 18: JFR Memory Leak Analysis with TLAB tracking

    +

    When to use: Advanced memory leak investigation
    +What it shows: Thread Local Allocation Buffer patterns and object lifecycle

    +

    TLAB (Thread Local Allocation Buffer) Explained:

    +

    TLAB is a JVM optimization technique that provides each thread with its own private allocation buffer in the heap's Eden space. This eliminates contention when multiple threads allocate objects simultaneously.

    +

    Key TLAB Concepts:
    +- Private Buffer: Each thread gets its own allocation space (typically 1-256KB)
    +- Fast Allocation: Objects are allocated via simple pointer bumping (no synchronization)
    +- Automatic Management: JVM automatically manages TLAB size based on allocation patterns
    +- Waste Tracking: Unused TLAB space is tracked as "waste" for performance tuning

    +

    TLAB and Memory Leaks:
    +- Allocation Patterns: TLAB tracking reveals which threads allocate the most objects
    +- Leak Detection: Threads with consistently growing TLAB usage may indicate leaks
    +- Performance Impact: Memory leaks can cause frequent TLAB allocation/deallocation
    +- GC Pressure: Excessive TLAB waste increases garbage collection frequency

    +

    Profiling with TLAB:
    +- JFR Events: jdk.ObjectAllocationInNewTLAB and jdk.ObjectAllocationOutsideTLAB
    +- Allocation Tracking: Monitor allocation rates per thread
    +- Waste Analysis: Identify threads with high TLAB waste ratios
    +- Correlation: Cross-reference TLAB data with memory leak patterns

    +
    ./profile-java-process.sh
+# Select: 18. JFR Memory Leak Analysis with TLAB tracking
+
    +

    🎯 Practical Exercise 4: Advanced JFR Analysis

    +
      +
    1. Execute TLAB tracking (10 minutes):
      2. +
    +
    ./profile-java-process.sh
+# Select option 18
+# Enter duration: 10 (minutes)
+
    +
      +
    1. Generate intensive allocation load:
      2. +
    +
    # High-frequency allocations to trigger TLAB behavior
+for i in {1..1000}; do
+  curl -X POST http://localhost:8080/api/v1/objects/create
+  if [ $((i % 100)) -eq 0 ]; then
+    echo "Completed $i allocations"
+  fi
+done
+
    +

    Expected Results:

    +
    File: memory-leak-tlab-YYYYMMDD-HHMMSS.jfr
+Analysis tools: JProfiler, VisualVM, Mission Control
+Key insights: TLAB allocation patterns, object aging, GC behavior
+
    +
    +

    πŸ”₯ Flamegraph Interpretation Masterclass

    +

    Understanding Flamegraph Anatomy

    +
    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
+β”‚  Stack Depth (Y-axis) - Call hierarchy depth                β”‚
+β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”    β”‚
+β”‚  β”‚ main() ──────────────────────────────────────────── β”‚    β”‚
+β”‚  β”‚  └─ CocoController.createObject() ───────────────── β”‚    β”‚
+β”‚  β”‚     └─ ArrayList.add() ──────────────────────────   β”‚    β”‚
+β”‚  β”‚        └─ MyPojo.<init>() ─────────────────────     β”‚    β”‚
+β”‚  β”‚           └─ String repetition ──────────────       β”‚    β”‚
+β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜    β”‚
+β”‚           Width (X-axis) - Time/Resource consumption        β”‚
+β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
+
    +

    Key Visual Patterns for Memory Leaks

    +

    1. Wide Allocation Patterns

    +
    CocoController.createObject() β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ
+└─ ArrayList.add()           β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ
+   └─ MyPojo.<init>()        β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ
+
    +

    Interpretation: Consistent, wide sections indicate high-frequency allocations

    +

    2. Growing Canvas Height

    +
    Run 1 (Baseline):  Canvas height ~200px
+Run 2 (5 minutes): Canvas height ~400px
+Run 3 (10 minutes): Canvas height ~600px
+
    +

    Interpretation: Increasing complexity suggests accumulating allocation paths

    +

    3. Stack Depth Patterns

    +
    Healthy Application:    3-5 levels deep
+Memory Leak Pattern:    8-12 levels deep
+Critical Leak:          15+ levels deep
+
    +

    πŸ” Knowledge Check

    +

    Look at your generated flamegraphs and answer:
    +1. What is the canvas height of your memory-leak detection report?
    +2. Which method shows the widest section?
    +3. How many stack levels deep are the main allocation patterns?

    +

    🎯 Practical Exercise 5: Comparative Flamegraph Analysis

    +
      +
    1. Generate multiple flamegraphs with different durations:
      2. +
    +
    # Short-term (30s)
+./profile-java-process.sh  # Option 2
+
+# Medium-term (60s)
+./profile-java-process.sh  # Option 7, duration: 60
+
+# Long-term (300s)
+./profile-java-process.sh  # Option 8
+
    +
      +
    1. Create comparison table:
      2. +
    +
    | Duration | Canvas Height | Widest Method | Stack Depth | File Size |
+|----------|---------------|---------------|-------------|-----------|
+| 30s      | [measure]     | [identify]    | [count]     | [size]    |
+| 60s      | [measure]     | [identify]    | [count]     | [size]    |
+| 300s     | [measure]     | [identify]    | [count]     | [size]    |
+
    +
      +
    1. Document visual patterns:
      2. +
    +
      +
    • Take screenshots of key sections
      • +
    • Note color patterns and distributions
      • +
    • Identify recurring allocation patterns
      • +
    +
    +

    πŸŽ›οΈ JMeter Integration for Consistent Profiling

    +

    Understanding the Load Testing Integration

    +

    The demo includes sophisticated JMeter integration for realistic profiling scenarios:

    +
    # View available JMeter options
+./run-jmeter.sh --help
+
    +

    Key JMeter Parameters:
    +- -t, --time: Test duration in seconds
    +- -c, --concurrency: Number of concurrent users
    +- -r, --ramp-up: Ramp-up time in seconds
    +- -e, --endpoints: Which endpoints to test (objects, threads, both)

    +

    🎯 Practical Exercise 6: Advanced Load Testing Scenarios

    +

    Scenario 1: Burst Load Testing

    +
    # High concurrency, short duration
+./run-jmeter.sh -t 120 -c 20 -r 10 -e both
+
    +

    Use case: Simulating peak traffic conditions
    +Profiling pairing: Use with Option 2 (Memory Allocation) for burst pattern analysis

    +

    Scenario 2: Sustained Load Testing

    +
    # Moderate concurrency, long duration
+./run-jmeter.sh -t 600 -c 5 -r 30 -e objects
+
    +

    Use case: Simulating normal production load
    +Profiling pairing: Use with Option 8 (Memory Leak Detection) for accumulation patterns

    +

    Scenario 3: Gradual Ramp Testing

    +
    # Increasing load over time
+./run-jmeter.sh -t 300 -c 10 -r 120 -e both
+
    +

    Use case: Simulating growing user base
    +Profiling pairing: Use with Option 9 (Complete Workflow) for comprehensive analysis

    +

    Creating Custom Load Patterns

    +
    # Create custom JMeter test plan
+cat > custom-memory-leak-test.jmx << 'EOF'
+<?xml version="1.0" encoding="UTF-8"?>
+<jmeterTestPlan version="1.2">
+  <!-- Custom test plan for memory leak detection -->
+  <hashTree>
+    <TestPlan testname="Memory Leak Detection Test">
+      <elementProp name="TestPlan.arguments" elementType="Arguments" guiclass="ArgumentsPanel">
+        <collectionProp name="Arguments.arguments">
+          <elementProp name="objects_per_minute" elementType="Argument">
+            <stringProp name="Argument.name">objects_per_minute</stringProp>
+            <stringProp name="Argument.value">60</stringProp>
+          </elementProp>
+        </collectionProp>
+      </elementProp>
+    </TestPlan>
+    <!-- Add your custom test scenarios here -->
+  </hashTree>
+</jmeterTestPlan>
+EOF
+
    +
    +

    πŸ“Š Evidence Collection and Documentation

    +

    Systematic Evidence Collection Framework

    +

    For each profiling session, collect:

    +

    1. Technical Metrics

    +
    # Create evidence collection script
+cat > collect-evidence.sh << 'EOF'
+#!/bin/bash
+TIMESTAMP=$(date +%Y%m%d-%H%M%S)
+EVIDENCE_DIR="profiler/evidence-$TIMESTAMP"
+mkdir -p "$EVIDENCE_DIR"
+
+echo "Collecting evidence at $TIMESTAMP"
+
+# System information
+echo "=== System Info ===" > "$EVIDENCE_DIR/system-info.txt"
+java -version >> "$EVIDENCE_DIR/system-info.txt" 2>&1
+free -h >> "$EVIDENCE_DIR/system-info.txt"
+nproc >> "$EVIDENCE_DIR/system-info.txt"
+
+# Application status
+echo "=== App Status ===" > "$EVIDENCE_DIR/app-status.txt"
+curl -s http://localhost:8080/actuator/health >> "$EVIDENCE_DIR/app-status.txt"
+curl -s http://localhost:8080/actuator/metrics/jvm.memory.used >> "$EVIDENCE_DIR/app-status.txt"
+
+# Configuration
+echo "=== Configuration ===" > "$EVIDENCE_DIR/config.txt"
+curl -s http://localhost:8080/actuator/env/coco >> "$EVIDENCE_DIR/config.txt"
+
+echo "Evidence collected in $EVIDENCE_DIR"
+EOF
+chmod +x collect-evidence.sh
+
    +

    2. Visual Documentation

    +
      +
    • Screenshot key flamegraph sections
      • +
    • Document canvas heights and widths
      • +
    • Note color patterns and distributions
      • +
    • Capture browser developer tools memory graphs
      • +
    +

    3. Quantitative Measurements

    +
    # Measure flamegraph characteristics
+cat > measure-flamegraph.sh << 'EOF'
+#!/bin/bash
+HTML_FILE="$1"
+if [ -z "$HTML_FILE" ]; then
+    echo "Usage: $0 <flamegraph.html>"
+    exit 1
+fi
+
+echo "Analyzing flamegraph: $HTML_FILE"
+echo "File size: $(wc -c < "$HTML_FILE") bytes"
+echo "Estimated canvas height: $(grep -o 'height="[0-9]*"' "$HTML_FILE" | head -1 | grep -o '[0-9]*') pixels"
+echo "Number of stack frames: $(grep -c 'class="func_g"' "$HTML_FILE")"
+EOF
+chmod +x measure-flamegraph.sh
+
    +
    +

    🎯 Module 2 Assessment

    +

    Hands-on Proficiency Checklist

    +

    βœ… Interactive Script Mastery:
    +- [ ] Successfully navigated all 21 profiling options
    +- [ ] Executed memory allocation profiling (Option 2)
    +- [ ] Completed 5-minute memory leak detection (Option 8)
    +- [ ] Generated complete memory analysis workflow (Option 9)
    +- [ ] Used advanced JFR analysis with TLAB tracking (Option 18)

    +

    βœ… Flamegraph Interpretation:
    +- [ ] Can identify wide allocation patterns
    +- [ ] Measures canvas height accurately
    +- [ ] Counts stack depth levels
    +- [ ] Recognizes memory leak visual signatures

    +

    βœ… Load Testing Integration:
    +- [ ] Executed coordinated JMeter load testing
    +- [ ] Created custom load patterns
    +- [ ] Synchronized profiling with realistic load
    +- [ ] Generated consistent, reproducible results

    +

    βœ… Evidence Collection:
    +- [ ] Documented technical metrics for each session
    +- [ ] Captured visual evidence of flamegraph patterns
    +- [ ] Created quantitative measurements
    +- [ ] Organized evidence for systematic analysis

    +

    🎯 Advanced Challenge: Custom Profiling Strategy

    +

    Challenge: Design a custom profiling strategy for a specific memory leak scenario

    +

    Requirements:
    +1. Scenario Definition: Define a specific memory leak pattern to investigate
    +2. Tool Selection: Choose appropriate profiling options from the 21 available
    +3. Load Pattern: Design matching JMeter load testing
    +4. Evidence Plan: Define what evidence to collect
    +5. Success Criteria: Establish measurable outcomes

    +

    Example Template:

    +
    # Custom Profiling Strategy: [Scenario Name]
+
+## Scenario
+- **Leak Type**: [Collection/Thread Pool/Cache/etc.]
+- **Symptoms**: [Expected behavior patterns]
+- **Timeline**: [How long to observe]
+
+## Profiling Plan
+- **Primary Tool**: Option X - [Name and rationale]
+- **Supporting Tools**: Option Y, Z - [Supporting evidence]
+- **Duration Strategy**: [Short/Medium/Long term analysis]
+
+## Load Testing
+- **JMeter Configuration**: [Specific parameters]
+- **Load Pattern**: [Burst/Sustained/Gradual]
+- **Endpoint Focus**: [Which APIs to exercise]
+
+## Evidence Collection
+- **Visual**: [What flamegraph patterns to document]
+- **Quantitative**: [Specific metrics to measure]
+- **Comparative**: [What to compare against]
+
+## Success Criteria
+- [ ] [Measurable outcome 1]
+- [ ] [Measurable outcome 2]
+- [ ] [Measurable outcome 3]
+
    +
    +

    πŸš€ Transition to Module 3

    +

    Excellent progress! You've successfully:
    +- βœ… Mastered the 21-option interactive profiling script
    +- βœ… Generated comprehensive memory leak evidence
    +- βœ… Integrated realistic load testing with profiling
    +- βœ… Developed flamegraph interpretation skills
    +- βœ… Created systematic evidence collection processes

    +

    What's Next?

    +

    In Module 3: Analysis and Evidence Collection, we'll focus on:
    +- Systematic analysis using @162-java-profiling-analyze
    +- Creating structured documentation from profiling evidence
    +- Developing prioritized solution recommendations
    +- Cross-correlating multiple profiling results for comprehensive insights

    +

    πŸ’‘ Key Takeaway

    +

    "Effective profiling is not just about collecting data - it's about collecting the RIGHT data under the RIGHT conditions to answer SPECIFIC questions about your application's performance!"

    +

    Ready to transform your profiling data into actionable insights? Let's continue to Module 3! πŸ”

    + + +
    +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/courses/profile-memory-leak/module-3-analysis.html b/docs/courses/profile-memory-leak/module-3-analysis.html new file mode 100644 index 00000000..72d13548 --- /dev/null +++ b/docs/courses/profile-memory-leak/module-3-analysis.html @@ -0,0 +1,712 @@ + + + + + + + + Module 3: Analysis and Evidence Collection - Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    +
    +
    +
    +
    +

    Module 3: Analysis and Evidence Collection

    +
    +
    +
    +
    +
    +
    + + +
    +
    +
    +
    + +
    + + 2025-09-17 +   + + Juan Antonio BreΓ±a Moral +   + + Version 0.11.0-SNAPSHOT +
    +   + + java + profiling + memory-leak + analysis + evidence + documentation +
    +
    +
    + +

    Systematic Analysis using @162-java-profiling-analyze

    +

    ⏱️ Duration: 2 hours
    +🎯 Learning Objectives:
    +- Master the systematic analysis framework from @162-java-profiling-analyze
    +- Learn to categorize and prioritize performance issues using Impact/Effort scoring
    +- Create structured documentation following professional templates
    +- Develop cross-correlation analysis skills for multiple profiling results
    +- Generate actionable solution recommendations with implementation details

    +
    +

    🧠 The Systematic Analysis Framework

    +

    Understanding the @162-java-profiling-analyze Approach

    +

    The analysis system prompt provides a structured methodology that transforms raw profiling data into actionable insights:

    +
    Raw Profiling Data β†’ Systematic Analysis β†’ Categorized Problems β†’ Prioritized Solutions
+
    +

    Key Principles:
    +1. Problem-First Analysis: Start with identifying specific issues, not just general observations
    +2. Evidence-Based Documentation: Every finding must reference specific profiling files and metrics
    +3. Quantitative Assessment: Use measurable criteria for impact and effort estimation
    +4. Cross-Correlation: Validate findings across multiple profiling sessions and file types

    +

    πŸ’‘ Learning Insight

    +

    The difference between novice and expert performance analysis is systematic methodology. Random observations lead to random fixes - structured analysis leads to systematic improvements!

    +
    +

    πŸ“Š Step 1: Inventory and Organize Your Profiling Results

    +

    🎯 Practical Exercise 1: Results Inventory

    +

    Let's organize the profiling data you've collected in Module 2:

    +
    cd ./cursor-rules-java/examples/spring-boot-memory-leak-demo
+
+# Create organized analysis workspace
+mkdir -p profiler/analysis-workspace
+cd profiler/analysis-workspace
+
+# Inventory all available results
+echo "=== PROFILING RESULTS INVENTORY ===" > results-inventory.md
+echo "Generated on: $(date)" >> results-inventory.md
+echo "" >> results-inventory.md
+
+# Categorize by file type
+echo "## Memory Allocation Reports" >> results-inventory.md
+ls -la ../results/allocation-flamegraph-*.html >> results-inventory.md 2>/dev/null || echo "None found" >> results-inventory.md
+
+echo "" >> results-inventory.md
+echo "## Memory Leak Detection Reports" >> results-inventory.md
+ls -la ../results/memory-leak-*.html >> results-inventory.md 2>/dev/null || echo "None found" >> results-inventory.md
+
+echo "" >> results-inventory.md
+echo "## JFR Recording Files" >> results-inventory.md
+ls -la ../results/*.jfr >> results-inventory.md 2>/dev/null || echo "None found" >> results-inventory.md
+
+echo "" >> results-inventory.md
+echo "## Thread Dumps" >> results-inventory.md
+ls -la ../results/threaddump-*.txt >> results-inventory.md 2>/dev/null || echo "None found" >> results-inventory.md
+
+echo "" >> results-inventory.md
+echo "## GC Log Files" >> results-inventory.md
+ls -la ../results/gc-*.log >> results-inventory.md 2>/dev/null || echo "None found" >> results-inventory.md
+
+cat results-inventory.md
+
    +

    File Organization Assessment

    +

    Create a systematic organization of your profiling evidence:

    +
    # Create analysis directory structure
+mkdir -p {evidence,analysis,solutions,reports}
+
+# Move/copy key files for analysis
+cp ../results/memory-leak-*.html evidence/ 2>/dev/null || echo "No memory leak reports found"
+cp ../results/allocation-flamegraph-*.html evidence/ 2>/dev/null || echo "No allocation reports found"
+cp ../results/*.jfr evidence/ 2>/dev/null || echo "No JFR files found"
+
+# Create file manifest
+ls -la evidence/ > file-manifest.txt
+echo "Analysis workspace prepared with $(ls evidence/ | wc -l) evidence files"
+
    +
    +

    πŸ” Step 2: Problem Identification and Categorization

    +

    Memory-Related Issues Analysis Framework

    +

    Based on the @162-java-profiling-analyze methodology, let's systematically analyze each type of issue:

    +

    🎯 Practical Exercise 2: Memory Leak Pattern Analysis

    +

    Open your memory leak detection flamegraph:

    +
    # Open the longest-duration memory leak report
+LEAK_REPORT=$(ls evidence/memory-leak-*.html | tail -1)
+echo "Analyzing: $LEAK_REPORT"
+
+# macOS
+open "$LEAK_REPORT"
+
+# Linux
+xdg-open "$LEAK_REPORT"
+
    +

    Systematic Analysis Checklist:

    +
      +
    1. Visual Pattern Assessment:
      2. +
    +
    ## Memory Leak Visual Analysis
+
+### Canvas Characteristics
+- **Canvas Height**: [measure in pixels]
+- **Canvas Width**: [measure in pixels]
+- **Overall Complexity**: [Low/Medium/High]
+
+### Stack Depth Analysis
+- **Maximum Stack Depth**: [count levels]
+- **Average Stack Depth**: [estimate]
+- **Deep Stack Patterns**: [identify methods with >10 levels]
+
+### Width Distribution Patterns
+- **Widest Method**: [identify method name]
+- **Width Percentage**: [estimate % of total width]
+- **Consistent Wide Patterns**: [list recurring wide sections]
+
    +
      +
    1. Quantitative Measurements:
      2. +
    +
    # Create measurement script
+cat > measure-flamegraph.sh << 'EOF'
+#!/bin/bash
+HTML_FILE="$1"
+if [ -z "$HTML_FILE" ]; then
+    echo "Usage: $0 <flamegraph.html>"
+    exit 1
+fi
+
+echo "=== FLAMEGRAPH MEASUREMENTS ==="
+echo "File: $(basename "$HTML_FILE")"
+echo "Size: $(wc -c < "$HTML_FILE") bytes"
+echo "Generated: $(stat -c %y "$HTML_FILE" 2>/dev/null || stat -f %Sm "$HTML_FILE")"
+
+# Extract technical details from HTML
+echo "Canvas height: $(grep -o 'height="[0-9]*"' "$HTML_FILE" | head -1 | grep -o '[0-9]*') pixels"
+echo "Stack frames: $(grep -c 'class="func_g"' "$HTML_FILE") elements"
+echo "Text elements: $(grep -c '<text' "$HTML_FILE") labels"
+
+# Estimate complexity
+FRAMES=$(grep -c 'class="func_g"' "$HTML_FILE")
+if [ "$FRAMES" -gt 1000 ]; then
+    echo "Complexity: HIGH (>1000 frames)"
+elif [ "$FRAMES" -gt 500 ]; then
+    echo "Complexity: MEDIUM (500-1000 frames)"
+else
+    echo "Complexity: LOW (<500 frames)"
+fi
+EOF
+chmod +x measure-flamegraph.sh
+
+# Measure all your flamegraphs
+for file in evidence/*.html; do
+    ./measure-flamegraph.sh "$file"
+    echo "---"
+done
+
    +

    🎯 Practical Exercise 3: Cross-File Correlation Analysis

    +

    Compare patterns across different profiling sessions:

    +
    # Create correlation analysis
+cat > correlation-analysis.md << 'EOF'
+# Cross-File Correlation Analysis
+
+## Allocation vs Leak Detection Comparison
+
+| Metric | 30s Allocation | 5min Leak Detection | Correlation |
+|--------|----------------|-------------------|-------------|
+| Canvas Height | [measure] | [measure] | [growing/stable/shrinking] |
+| Widest Method | [identify] | [identify] | [same/different] |
+| Stack Complexity | [count] | [count] | [increasing/stable] |
+| File Size | [bytes] | [bytes] | [ratio] |
+
+## Pattern Consistency Analysis
+
+### Recurring Allocation Patterns
+- [ ] CocoController.createObject appears in all reports
+- [ ] ArrayList.add shows consistent width
+- [ ] MyPojo allocation patterns are reproducible
+- [ ] String operations show expected behavior
+
+### Temporal Pattern Changes
+- [ ] Short-term reports show basic patterns
+- [ ] Long-term reports show accumulation
+- [ ] Stack depth increases over time
+- [ ] Method width consistency maintained
+
+## Evidence Correlation Score
+- **Strong Correlation (3/3)**: Patterns consistent across all timeframes
+- **Moderate Correlation (2/3)**: Some variations but clear trends
+- **Weak Correlation (1/3)**: Inconsistent patterns, need more data
+EOF
+
+# Fill in the template with your actual measurements
+echo "Edit correlation-analysis.md with your specific measurements"
+
    +
    +

    πŸ“ Step 3: Structured Documentation Creation

    +

    Creating the Problem Analysis Document

    +

    Following the @162-java-profiling-analyze template:

    +
    # Create the problem analysis document
+DATE_SUFFIX=$(date +%Y%m%d)
+cat > analysis/profiling-problem-analysis-${DATE_SUFFIX}.md << 'EOF'
+# Profiling Problem Analysis - [DATE]
+
+## Executive Summary
+- **Analysis Date**: [Current Date]
+- **Application**: Spring Boot Memory Leak Demo
+- **Configuration**: coco=true (memory leaks enabled)
+- **Profiling Duration**: [Total time spent profiling]
+- **Severity Classification**: CRITICAL - Active memory leaks detected
+- **Impact Assessment**: Memory exhaustion risk under sustained load
+
+## Detailed Findings
+
+### 1. Unbounded Object Accumulation (CRITICAL)
+- **Description**: CocoController.createObject() method continuously adds objects to ArrayList without bounds checking
+- **Evidence**:
+  - File: `memory-leak-YYYYMMDD-HHMMSS.html`
+  - Pattern: Consistent wide sections in CocoController allocation paths
+  - Measurement: Canvas height [X] pixels, [Y] stack frames
+- **Impact**: Linear memory growth leading to eventual OutOfMemoryError
+- **Root Cause**: Missing collection size limits and cleanup logic
+
+### 2. Thread Pool Resource Leaks (HIGH)
+- **Description**: ExecutorService instances created without proper lifecycle management
+- **Evidence**:
+  - File: `allocation-flamegraph-YYYYMMDD-HHMMSS.html`
+  - Pattern: Thread creation patterns without corresponding cleanup
+  - Measurement: [X] thread-related allocations detected
+- **Impact**: Thread pool exhaustion and native memory leaks
+- **Root Cause**: Missing @PreDestroy cleanup and shared resource management
+
+### 3. String Allocation Inefficiencies (MEDIUM)
+- **Description**: Repeated string operations creating unnecessary object allocations
+- **Evidence**:
+  - File: `memory-leak-YYYYMMDD-HHMMSS.html`
+  - Pattern: String concatenation and repetition in MyPojo constructor
+  - Measurement: [X]% of allocations attributed to String operations
+- **Impact**: Increased GC pressure and memory churn
+- **Root Cause**: Inefficient string handling in object initialization
+
+## Methodology
+- **Profiling Tools Used**: async-profiler v4.1, JFR analysis
+- **Data Collection Approach**: Multi-duration analysis (30s, 5min, comprehensive workflow)
+- **Load Testing**: JMeter coordinated load testing for realistic conditions
+- **Analysis Techniques Applied**: Flamegraph visual analysis, quantitative measurements, cross-correlation
+
+## Recommendations Priority
+1. **CRITICAL (Immediate)**: Implement collection bounds and thread pool lifecycle management
+2. **HIGH (This Sprint)**: Add resource cleanup patterns and monitoring
+3. **MEDIUM (Next Sprint)**: Optimize string operations and allocation patterns
+4. **LOW (Future)**: Performance monitoring and alerting infrastructure
+
+## Supporting Evidence Files
+- Memory leak detection: `../evidence/memory-leak-*.html`
+- Allocation analysis: `../evidence/allocation-flamegraph-*.html`
+- JFR recordings: `../evidence/*.jfr`
+- Measurements: `../correlation-analysis.md`
+
+## Next Steps
+1. Proceed to solution development (Module 4)
+2. Implement fixes using coco=false configuration
+3. Validate improvements through comparative analysis (Module 5)
+EOF
+
+echo "Problem analysis document created: analysis/profiling-problem-analysis-${DATE_SUFFIX}.md"
+echo "Please edit the template with your specific measurements and findings"
+
    +

    🎯 Practical Exercise 4: Impact/Effort Prioritization

    +

    Implement the Impact/Effort scoring framework:

    +
    # Create prioritization analysis
+cat > analysis/impact-effort-prioritization.md << 'EOF'
+# Impact/Effort Prioritization Analysis
+
+## Scoring Framework
+- **Impact Score (1-5)**: 5=Critical performance degradation, 1=Cosmetic optimization
+- **Effort Score (1-5)**: 1=Configuration change, 5=Architecture change
+- **Priority = Impact / Effort**: Higher scores = Higher priority
+
+## Issue Prioritization Matrix
+
+| Issue | Impact | Effort | Priority | Rationale |
+|-------|---------|--------|----------|-----------|
+| Unbounded Collections | 5 | 1 | 5.0 | Critical leak, config change fix |
+| Thread Pool Leaks | 4 | 2 | 2.0 | High impact, moderate refactoring |
+| String Inefficiencies | 2 | 3 | 0.67 | Low impact, requires code changes |
+| Missing Monitoring | 3 | 2 | 1.5 | Medium impact, setup required |
+
+## Implementation Order
+1. **Priority 5.0**: Unbounded Collections (Immediate - configuration change)
+2. **Priority 2.0**: Thread Pool Leaks (This week - class refactoring)
+3. **Priority 1.5**: Missing Monitoring (Next week - infrastructure setup)
+4. **Priority 0.67**: String Inefficiencies (Future - performance optimization)
+
+## Resource Allocation
+- **Week 1**: Focus on Priority 5.0 and 2.0 items (80% of impact with 20% of effort)
+- **Week 2**: Address monitoring and validation
+- **Week 3+**: Performance optimizations and enhancements
+EOF
+
+echo "Prioritization analysis created"
+
    +
    +

    🎯 Step 4: Solution Development Framework

    +

    Creating the Solutions Document

    +
    # Create comprehensive solutions document
+DATE_SUFFIX=$(date +%Y%m%d)
+cat > solutions/profiling-solutions-${DATE_SUFFIX}.md << 'EOF'
+# Profiling Solutions and Recommendations - [DATE]
+
+## Quick Wins (Low effort, High impact)
+
+### Solution 1: Enable Fixed Controller Implementation
+- **Problem**: Critical memory leaks in CocoController causing unbounded growth
+- **Solution**: Switch to NoCocoController using coco=false configuration
+- **Expected Impact**: Eliminate memory leaks immediately, stabilize memory usage
+- **Implementation Effort**: 5 minutes (configuration change)
+- **Code Changes**:
+  ```properties
+  # application.properties
+  coco=false
+
    +
      +
    • Validation: Memory usage should stabilize within 30 minutes of change
      • +
    +

    Solution 2: Implement Collection Bounds

    +
      +
    • Problem: ArrayList grows without limits leading to memory exhaustion
      • +
    • Solution: Add MAX_OBJECTS constant and bounds checking
      • +
    • Expected Impact: Cap memory usage, provide graceful degradation
      • +
    • Implementation Effort: 30 minutes (add bounds checking)
      • +
    • Code Changes:
      • +
    +
    private static final int MAX_OBJECTS = 10000;
+
+if (objects.size() >= MAX_OBJECTS) {
+    return ResponseEntity.badRequest()
+        .body("Maximum objects limit reached: " + MAX_OBJECTS);
+}
+
    +

    Medium-term Improvements

    +

    Solution 3: Thread Pool Lifecycle Management

    +
      +
    • Problem: ExecutorService instances created without cleanup
      • +
    • Solution: Implement shared thread pool with proper @PreDestroy cleanup
      • +
    • Expected Impact: Eliminate thread leaks, reduce resource overhead by 90%
      • +
    • Implementation Effort: 2 hours (class refactoring)
      • +
    • Code Changes: Already implemented in NoCocoController
      • +
    +
    private final ExecutorService sharedExecutorService =
+    Executors.newFixedThreadPool(10, new CustomizableThreadFactory("shared-pool-"));
+
+@PreDestroy
+public void cleanup() throws InterruptedException {
+    sharedExecutorService.shutdown();
+    if (!sharedExecutorService.awaitTermination(30, TimeUnit.SECONDS)) {
+        sharedExecutorService.shutdownNow();
+    }
+}
+
    +

    Long-term Optimizations

    +

    Solution 4: Performance Monitoring Infrastructure

    +
      +
    • Problem: No early warning system for memory leaks
      • +
    • Solution: Implement comprehensive memory monitoring and alerting
      • +
    • Expected Impact: Prevent future memory leak incidents
      • +
    • Implementation Effort: 1 day (monitoring setup)
      • +
    • Code Changes: JVM monitoring flags and dashboard configuration
      • +
    +

    Implementation Plan

    +

    Phase 1: Emergency Response (Next Hour)

    +
      +
    1. Immediate: Switch to coco=false configuration
      2. +
    2. Validation: Run 30-minute stability test
      3. +
    3. Verification: Confirm memory usage stabilizes
      4. +
    +

    Phase 2: Stabilization (Next 24 Hours)

    +
      +
    1. Deploy monitoring: Implement memory usage alerts
      2. +
    2. Load testing: Run sustained load test to verify fix
      3. +
    3. Documentation: Update analysis with results
      4. +
    +

    Phase 3: Prevention (Next Week)

    +
      +
    1. Process improvement: Add profiling to CI/CD pipeline
      2. +
    2. Team training: Review memory leak detection procedures
      3. +
    3. Monitoring enhancement: Create comprehensive performance dashboard
      4. +
    +

    Success Criteria

    +

    Immediate Success (1 Hour)

    +
      +
    • [ ] Memory usage stabilizes below baseline
      • +
    • [ ] No memory growth under 30-minute load test
      • +
    • [ ] Application remains responsive
      • +
    +

    Short-term Success (24 Hours)

    +
      +
    • [ ] Memory patterns remain stable over 6-hour test
      • +
    • [ ] GC frequency within acceptable limits
      • +
    • [ ] Response times meet SLA requirements
      • +
    +

    Long-term Success (1 Week)

    +
      +
    • [ ] No memory leaks detected in continuous profiling
      • +
    • [ ] Performance monitoring alerts configured
      • +
    • [ ] Team knowledge transfer completed
      • +
    +

    Risk Mitigation

    +
      +
    • Deployment Risk: Use feature flags for gradual rollout
      • +
    • Performance Risk: Comprehensive load testing before production
      • +
    • Regression Risk: Automated profiling in CI/CD pipeline
      +EOF
      • +
    +

    echo "Solutions document created: solutions/profiling-solutions-${DATE_SUFFIX}.md"

    +
    
+---
+
+## πŸ“Š Step 5: Cross-Correlation and Validation
+
+### **🎯 Practical Exercise 5: Multi-Source Evidence Correlation**
+
+Create a comprehensive evidence correlation matrix:
+
+```bash
+# Create evidence correlation analysis
+cat > analysis/evidence-correlation-matrix.md << 'EOF'
+# Evidence Correlation Matrix
+
+## Data Source Cross-Validation
+
+### Flamegraph Evidence Consistency
+| Evidence Type | File 1 | File 2 | File 3 | Consistency Score |
+|---------------|---------|--------|--------|------------------|
+| Allocation Patterns | CocoController.createObject | [same/different] | [same/different] | [3/3, 2/3, 1/3] |
+| Stack Depth | [X levels] | [Y levels] | [Z levels] | [growing/stable/shrinking] |
+| Method Width | [X% canvas] | [Y% canvas] | [Z% canvas] | [consistent/variable] |
+
+### Temporal Pattern Validation
+| Time Period | Memory Growth | GC Pressure | Thread Creation | Validation |
+|-------------|---------------|-------------|-----------------|------------|
+| 0-30s | [baseline] | [normal] | [initial] | βœ… Expected |
+| 30s-5min | [growing] | [increasing] | [accumulating] | βœ… Leak confirmed |
+| 5min+ | [critical] | [high] | [excessive] | βœ… Critical state |
+
+### Load Testing Correlation
+| Load Pattern | Memory Impact | Expected Behavior | Actual Behavior | Match |
+|-------------|---------------|-------------------|-----------------|-------|
+| Burst Load | High allocation spike | βœ… Confirmed | [your observation] | [βœ…/❌] |
+| Sustained Load | Linear growth | βœ… Confirmed | [your observation] | [βœ…/❌] |
+| No Load | Stable baseline | βœ… Confirmed | [your observation] | [βœ…/❌] |
+
+## Confidence Assessment
+- **High Confidence (3/3 sources agree)**: [List findings with high confidence]
+- **Medium Confidence (2/3 sources agree)**: [List findings with medium confidence]
+- **Low Confidence (1/3 sources agree)**: [List findings requiring more investigation]
+
+## Recommendation Validation
+- **Strongly Supported**: Solutions backed by multiple evidence sources
+- **Moderately Supported**: Solutions backed by primary evidence
+- **Weakly Supported**: Solutions requiring additional validation
+EOF
+
+echo "Fill in the correlation matrix with your specific observations"
+
    +
    +

    🎯 Module 3 Assessment

    +

    Comprehensive Analysis Checklist

    +

    βœ… Systematic Analysis Mastery:
    +- [ ] Completed results inventory and organization
    +- [ ] Applied structured problem identification framework
    +- [ ] Created quantitative measurements for all flamegraphs
    +- [ ] Performed cross-file correlation analysis
    +- [ ] Documented findings using professional templates

    +

    βœ… Documentation Excellence:
    +- [ ] Created problem analysis document following template
    +- [ ] Developed prioritized solutions with Impact/Effort scoring
    +- [ ] Generated implementation plan with timeline
    +- [ ] Established success criteria and validation methods

    +

    βœ… Evidence-Based Reasoning:
    +- [ ] Every finding references specific profiling files
    +- [ ] Quantitative metrics support all conclusions
    +- [ ] Cross-correlation validates findings across multiple sources
    +- [ ] Confidence levels assigned to each recommendation

    +

    βœ… Professional Communication:
    +- [ ] Executive summary suitable for management
    +- [ ] Technical details appropriate for development team
    +- [ ] Implementation guidance actionable and specific
    +- [ ] Risk assessment and mitigation strategies included

    +

    🎯 Advanced Challenge: Comprehensive Analysis Report

    +

    Challenge: Create a complete analysis package suitable for presentation to senior management and development teams.

    +

    Requirements:
    +1. Executive Presentation: 3-slide summary of critical findings
    +2. Technical Deep-dive: Complete analysis with all supporting evidence
    +3. Implementation Roadmap: Detailed timeline with resource requirements
    +4. ROI Analysis: Quantified impact of proposed solutions
    +5. Risk Assessment: Comprehensive risk analysis with mitigation strategies

    +

    Deliverables:

    +
    # Create final analysis package
+mkdir -p reports/final-analysis-package
+cd reports/final-analysis-package
+
+# Copy all analysis documents
+cp ../../analysis/* .
+cp ../../solutions/* .
+
+# Create executive summary
+cat > executive-summary.md << 'EOF'
+# Executive Summary: Memory Leak Analysis
+
+## Critical Findings
+- **Issue**: Active memory leaks causing 318% memory retention increase
+- **Impact**: Application will crash under sustained production load
+- **Solution**: Configuration change can resolve immediately (5-minute fix)
+- **Investment**: Minimal effort, maximum impact
+
+## Recommended Action
+1. **Immediate**: Deploy coco=false configuration (5 minutes)
+2. **Short-term**: Implement monitoring and validation (1 day)
+3. **Long-term**: Enhance performance monitoring (1 week)
+
+## Business Impact
+- **Risk Mitigation**: Prevent production outages
+- **Performance**: Improve application stability
+- **Cost**: Minimal development investment
+- **Timeline**: Issue resolved within 1 hour
+EOF
+
+echo "Final analysis package created in reports/final-analysis-package/"
+
    +
    +

    πŸš€ Transition to Module 4

    +

    Outstanding work! You've successfully:
    +- βœ… Applied systematic analysis methodology from @162-java-profiling-analyze
    +- βœ… Created comprehensive problem documentation with quantitative evidence
    +- βœ… Developed prioritized solutions using Impact/Effort framework
    +- βœ… Performed cross-correlation analysis across multiple data sources
    +- βœ… Generated professional-grade analysis reports

    +

    What's Next?

    +

    In Module 4: Refactoring and Solution Implementation, we'll focus on:
    +- Implementing the prioritized solutions you've identified
    +- Using the coco=false configuration to resolve memory leaks
    +- Validating that fixes are properly applied and effective
    +- Setting up monitoring and alerting for ongoing protection

    +

    πŸ’‘ Key Takeaway

    +

    "Systematic analysis transforms raw profiling data into actionable business intelligence. Your structured approach ensures that performance improvements are based on evidence, prioritized by impact, and communicated effectively to all stakeholders!"

    +

    Ready to implement your solutions and see the memory leaks disappear? Let's continue to Module 4! πŸ› οΈ

    + + +
    +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/courses/profile-memory-leak/module-4-refactoring.html b/docs/courses/profile-memory-leak/module-4-refactoring.html new file mode 100644 index 00000000..f06de94a --- /dev/null +++ b/docs/courses/profile-memory-leak/module-4-refactoring.html @@ -0,0 +1,681 @@ + + + + + + + + Module 4: Refactoring and Solution Implementation - Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    +
    +
    +
    +
    +

    Module 4: Refactoring and Solution Implementation

    +
    +
    +
    +
    +
    +
    + + +
    +
    +
    +
    + +
    + + 2025-09-17 +   + + Juan Antonio BreΓ±a Moral +   + + Version 0.11.0-SNAPSHOT +
    +   + + java + profiling + memory-leak + refactoring + implementation + validation +
    +
    +
    + +

    Implementing Memory Leak Fixes and Validation

    +

    ⏱️ Duration: 2 hours
    +🎯 Learning Objectives:
    +- Implement the prioritized solutions identified in Module 3
    +- Understand the coco=false configuration pattern for immediate leak resolution
    +- Understand proper resource lifecycle management patterns
    +- Validate that fixes are correctly applied and effective
    +- Set up monitoring and alerting for ongoing protection

    +
    +

    πŸš€ Implementation Strategy Overview

    +

    The Three-Phase Implementation Approach

    +

    Based on your analysis from Module 3, we'll implement solutions in priority order:

    +
      +
    1. Phase 1: Emergency Response (5 minutes) - Configuration change for immediate relief
      2. +
    2. Phase 2: Validation and Monitoring (30 minutes) - Verify fixes and establish monitoring
      3. +
    3. Phase 3: Long-term Improvements (1 hour) - Enhanced patterns and prevention
      4. +
    +

    πŸ’‘ Learning Insight

    +

    The beauty of the coco=false pattern is that it demonstrates the complete solution already implemented in NoCocoController. This allows you to see the "after" state immediately while learning the specific patterns that prevent memory leaks!

    +
    +

    ⚑ Phase 1: Emergency Response - Configuration Change

    +

    🎯 Practical Exercise 1: Immediate Memory Leak Resolution

    +

    Let's implement the highest-priority solution with immediate impact:

    +

    Step 1: Verify Current Configuration

    +
    cd ./cursor-rules-java/examples/spring-boot-memory-leak-demo
+
+# Check current configuration
+echo "=== Current Configuration Status ==="
+curl -s http://localhost:8080/actuator/env/coco | grep -E '"value"|"name"'
+
+# Verify which controller is active by testing endpoints
+echo "=== Testing Current Controller ==="
+RESPONSE=$(curl -s -X POST http://localhost:8080/api/v1/objects/create)
+echo "Object creation response: $RESPONSE"
+
+# Check current memory usage
+echo "=== Current Memory Usage ==="
+curl -s http://localhost:8080/actuator/metrics/jvm.memory.used | grep -E '"name"|"value"'
+
    +

    Step 2: Apply the Configuration Change

    +

    Method 1: Runtime Configuration Override (Immediate)

    +
    # Stop the current application
+# Press Ctrl+C in the terminal running the application
+
+# Restart with coco=false
+echo "Starting application with memory leak fixes enabled..."
+./run-java-process-for-profiling.sh --profile vt
+# This uses the application-vt.properties profile which has coco=false
+
    +

    Method 2: Direct Configuration File Edit (Permanent)

    +
    # Edit the main configuration file
+cp src/main/resources/application.properties src/main/resources/application.properties.backup
+
+# Change the configuration
+sed -i.bak 's/coco=true/coco=false/' src/main/resources/application.properties
+
+# Verify the change
+echo "=== Configuration Change Applied ==="
+grep coco src/main/resources/application.properties
+
+# Restart application
+./run-java-process-for-profiling.sh
+
    +

    Step 3: Immediate Validation

    +
    # Wait for application startup (30 seconds)
+sleep 30
+
+# Verify the configuration change took effect
+echo "=== Post-Change Configuration Verification ==="
+curl -s http://localhost:8080/actuator/env/coco
+
+# Test that fixed controller is now active
+echo "=== Testing Fixed Controller ==="
+for i in {1..5}; do
+    RESPONSE=$(curl -s -X POST http://localhost:8080/api/v1/objects/create)
+    echo "Test $i: $RESPONSE"
+done
+
+# Verify bounds checking is working
+echo "=== Testing Bounds Protection ==="
+# The fixed controller has MAX_OBJECTS=10000, but we can test the pattern
+curl -s -X POST http://localhost:8080/api/v1/objects/create | grep -E "created|limit"
+
    +

    πŸ” Understanding the Fix: Code Comparison

    +

    Let's examine exactly what changed:

    +
    # View the problematic implementation
+echo "=== PROBLEMATIC IMPLEMENTATION (CocoController) ==="
+grep -A 10 -B 2 "createObject" src/main/java/info/jab/ms/CocoController.java
+
+echo ""
+echo "=== FIXED IMPLEMENTATION (NoCocoController) ==="
+grep -A 15 -B 2 "createObject" src/main/java/info/jab/ms/NoCocoController.java
+
    +

    Key Differences Analysis:

    +

    Collection Bounds:
    +- CocoController (Problematic): objects.add(new MyPojo(...))
    +- NoCocoController (Fixed): if (objects.size() >= MAX_OBJECTS) bounds check
    +Error Handling:
    +- CocoController (Problematic): No bounds validation
    +- NoCocoController (Fixed): Returns 400 Bad Request when limit reached
    +Thread Management:
    +- CocoController (Problematic): Executors.newFixedThreadPool(5) per request
    +- NoCocoController (Fixed): Shared ExecutorService with lifecycle
    +Resource Cleanup:
    +- CocoController (Problematic): No cleanup logic
    +- NoCocoController (Fixed): @PreDestroy method with proper shutdown
    +Thread Safety:
    +- CocoController (Problematic): Basic ArrayList
    +- NoCocoController (Fixed): Collections.synchronizedList

    +

    πŸ’‘ Learning Reinforcement

    +

    Notice how the fixed implementation follows enterprise patterns: bounded collections, shared resources, lifecycle management, and graceful error handling. These aren't just memory leak fixes - they're production-ready design patterns!

    +
    +

    πŸ” Phase 2: Validation and Monitoring

    +

    🎯 Practical Exercise 2: Comprehensive Fix Validation

    +

    Step 1: Functional Validation

    +
    # Create comprehensive validation script
+cat > validate-fixes.sh << 'EOF'
+#!/bin/bash
+echo "=== MEMORY LEAK FIX VALIDATION ==="
+echo "Timestamp: $(date)"
+echo ""
+
+# Test 1: Configuration verification
+echo "1. Configuration Status:"
+CONFIG_RESPONSE=$(curl -s http://localhost:8080/actuator/env/coco)
+echo "$CONFIG_RESPONSE" | grep -E '"value"|"name"' | head -2
+
+# Test 2: Bounds checking validation
+echo ""
+echo "2. Bounds Checking Test:"
+for i in {1..10}; do
+    RESPONSE=$(curl -s -X POST http://localhost:8080/api/v1/objects/create)
+    echo "  Request $i: $RESPONSE"
+done
+
+# Test 3: Thread creation test
+echo ""
+echo "3. Thread Management Test:"
+for i in {1..5}; do
+    THREAD_RESPONSE=$(curl -s -X POST http://localhost:8080/api/v1/threads/create)
+    echo "  Thread test $i: $THREAD_RESPONSE"
+done
+
+# Test 4: Memory usage baseline
+echo ""
+echo "4. Memory Usage Check:"
+MEMORY_USED=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.used)
+echo "$MEMORY_USED" | grep -E '"value"' | head -1
+
+# Test 5: Application health
+echo ""
+echo "5. Application Health:"
+HEALTH=$(curl -s http://localhost:8080/actuator/health)
+echo "$HEALTH"
+
+echo ""
+echo "=== VALIDATION COMPLETE ==="
+EOF
+chmod +x validate-fixes.sh
+
+# Run validation
+./validate-fixes.sh
+
    +

    Step 2: Load Testing Validation

    +
    # Run sustained load test to verify stability
+echo "=== SUSTAINED LOAD TEST ==="
+echo "Running 10-minute stability test..."
+
+# Start JMeter load test
+./run-jmeter.sh -t 600 -c 3 -e both &
+JMETER_PID=$!
+
+# Monitor memory usage during load test
+echo "Monitoring memory usage every 30 seconds..."
+for i in {1..20}; do
+    TIMESTAMP=$(date '+%H:%M:%S')
+    MEMORY=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.used | grep -o '"value":[0-9]*' | grep -o '[0-9]*')
+    echo "$TIMESTAMP: Memory used: $MEMORY bytes"
+    sleep 30
+done
+
+# Wait for JMeter to complete
+wait $JMETER_PID
+echo "Load test completed successfully"
+
    +

    Step 3: Comparative Memory Analysis

    +
    # Generate post-fix profiling data for comparison
+echo "=== GENERATING POST-FIX PROFILING DATA ==="
+
+cd profiler/scripts
+./profile-java-process.sh
+# Select: 2. Memory Allocation Profiling (30s)
+# This will generate new flamegraphs with the fixes applied
+
+# Generate load during profiling
+cd ../..
+for i in {1..50}; do
+    curl -s -X POST http://localhost:8080/api/v1/objects/create > /dev/null
+    curl -s -X POST http://localhost:8080/api/v1/threads/create > /dev/null
+    sleep 1
+done
+
+echo "Post-fix profiling data generated"
+
    +
    +

    πŸ› οΈ Phase 3: Understanding the Implementation Patterns

    +

    Resource Lifecycle Management Deep Dive

    +

    Let's examine the specific patterns that prevent memory leaks:

    +

    🎯 Practical Exercise 3: Code Pattern Analysis

    +
    # Extract and analyze the key patterns
+echo "=== RESOURCE LIFECYCLE PATTERNS ==="
+
+# Pattern 1: Bounded Collections
+echo "1. Bounded Collection Pattern:"
+grep -A 5 -B 2 "MAX_OBJECTS" src/main/java/info/jab/ms/NoCocoController.java
+
+echo ""
+echo "2. Thread Pool Management Pattern:"
+grep -A 10 -B 2 "sharedExecutorService" src/main/java/info/jab/ms/NoCocoController.java
+
+echo ""
+echo "3. Resource Cleanup Pattern:"
+grep -A 10 -B 2 "@PreDestroy" src/main/java/info/jab/ms/NoCocoController.java
+
    +

    Understanding Each Pattern

    +

    1. Bounded Collections Pattern:

    +
    private static final int MAX_OBJECTS = 10000;
+private final List<MyPojo> objects = Collections.synchronizedList(new ArrayList<>());
+
+@PostMapping("/objects/create")
+public ResponseEntity<String> createObject() {
+    if (objects.size() >= MAX_OBJECTS) {
+        return ResponseEntity.badRequest()
+            .body("Maximum objects limit reached: " + MAX_OBJECTS);
+    }
+    objects.add(new MyPojo(UUID.randomUUID().toString(),
+                          "A".repeat(1000),
+                          System.currentTimeMillis()));
+    return ResponseEntity.ok("Object created: " + objects.size());
+}
+
    +

    Key Benefits:
    +- βœ… Memory Protection: Prevents unbounded growth
    +- βœ… Graceful Degradation: Returns meaningful error instead of crashing
    +- βœ… Thread Safety: Uses synchronized wrapper for concurrent access
    +- βœ… Monitoring: Provides current count for observability

    +

    2. Shared Thread Pool Pattern:

    +
    private final ExecutorService sharedExecutorService =
+    Executors.newFixedThreadPool(10, new CustomizableThreadFactory("shared-pool-"));
+
+@PostMapping("/threads/create")
+public ResponseEntity<String> createThread() {
+    sharedExecutorService.submit(() -> {
+        try {
+            Thread.sleep(1000);
+            log.info("Task executed in thread: {}", Thread.currentThread().getName());
+        } catch (InterruptedException e) {
+            Thread.currentThread().interrupt();
+        }
+    });
+    return ResponseEntity.ok("Task submitted to shared thread pool");
+}
+
    +

    Key Benefits:
    +- βœ… Resource Efficiency: Single shared pool vs. multiple pools
    +- βœ… Lifecycle Management: Proper initialization and cleanup
    +- βœ… Named Threads: CustomizableThreadFactory for debugging
    +- βœ… Interruption Handling: Proper interrupt signal management

    +

    3. Resource Cleanup Pattern:

    +
    @PreDestroy
+public void cleanup() throws InterruptedException {
+    log.info("Shutting down shared executor service...");
+    sharedExecutorService.shutdown();
+
+    if (!sharedExecutorService.awaitTermination(30, TimeUnit.SECONDS)) {
+        log.warn("Executor did not terminate gracefully, forcing shutdown...");
+        sharedExecutorService.shutdownNow();
+
+        if (!sharedExecutorService.awaitTermination(10, TimeUnit.SECONDS)) {
+            log.error("Executor did not terminate after forced shutdown");
+        }
+    }
+    log.info("Shared executor service shutdown complete");
+}
+
    +

    Key Benefits:
    +- βœ… Graceful Shutdown: Allows running tasks to complete
    +- βœ… Timeout Protection: Forces shutdown if graceful fails
    +- βœ… Logging: Provides visibility into shutdown process
    +- βœ… Resource Guarantee: Ensures threads are properly cleaned up

    +

    πŸ’‘ Learning Reinforcement

    +

    These patterns represent enterprise-grade resource management. The @PreDestroy pattern is especially important - it's Spring's way of ensuring cleanup happens during application shutdown, preventing resource leaks even during deployment cycles!

    +
    +

    πŸ“Š Monitoring and Alerting Setup

    +

    🎯 Practical Exercise 4: Implementing Memory Monitoring

    +

    Step 1: JVM Monitoring Configuration

    +
    # Add comprehensive JVM monitoring flags
+cat > monitoring-flags.txt << 'EOF'
+# Memory Monitoring JVM Flags
+-XX:+PrintGC
+-XX:+PrintGCDetails
+-XX:+PrintGCTimeStamps
+-XX:+PrintGCApplicationStoppedTime
+-Xloggc:gc-monitoring.log
+-XX:+UseGCLogFileRotation
+-XX:NumberOfGCLogFiles=5
+-XX:GCLogFileSize=10M
+
+# Memory Dump on OutOfMemoryError
+-XX:+HeapDumpOnOutOfMemoryError
+-XX:HeapDumpPath=./memory-dumps/
+
+# JFR Continuous Profiling
+-XX:+FlightRecorder
+-XX:StartFlightRecording=duration=1h,filename=continuous-monitoring.jfr,settings=profile
+EOF
+
+echo "Monitoring configuration created. Add these flags to your startup script."
+
    +

    Step 2: Application Metrics Monitoring

    +
    # Create memory monitoring script
+cat > monitor-memory.sh << 'EOF'
+#!/bin/bash
+MONITOR_DURATION=${1:-300}  # Default 5 minutes
+INTERVAL=${2:-10}           # Default 10 seconds
+
+echo "=== MEMORY MONITORING ==="
+echo "Duration: $MONITOR_DURATION seconds"
+echo "Interval: $INTERVAL seconds"
+echo "Timestamp,HeapUsed,HeapMax,NonHeapUsed,ObjectCount" > memory-monitor.csv
+
+START_TIME=$(date +%s)
+END_TIME=$((START_TIME + MONITOR_DURATION))
+
+while [ $(date +%s) -lt $END_TIME ]; do
+    TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
+
+    # Get heap memory usage
+    HEAP_USED=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.used?tag=area:heap | grep -o '"value":[0-9]*' | grep -o '[0-9]*')
+    HEAP_MAX=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.max?tag=area:heap | grep -o '"value":[0-9]*' | grep -o '[0-9]*')
+
+    # Get non-heap memory usage
+    NONHEAP_USED=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.used?tag=area:nonheap | grep -o '"value":[0-9]*' | grep -o '[0-9]*')
+
+    # Get object count from our controller
+    OBJECT_RESPONSE=$(curl -s -X POST http://localhost:8080/api/v1/objects/create)
+    OBJECT_COUNT=$(echo "$OBJECT_RESPONSE" | grep -o '[0-9]*$' || echo "0")
+
+    # Log to CSV
+    echo "$TIMESTAMP,$HEAP_USED,$HEAP_MAX,$NONHEAP_USED,$OBJECT_COUNT" >> memory-monitor.csv
+
+    # Display current status
+    HEAP_PCT=$((HEAP_USED * 100 / HEAP_MAX))
+    echo "[$TIMESTAMP] Heap: ${HEAP_PCT}% ($HEAP_USED/$HEAP_MAX bytes), Objects: $OBJECT_COUNT"
+
+    sleep $INTERVAL
+done
+
+echo "Monitoring complete. Data saved to memory-monitor.csv"
+EOF
+chmod +x monitor-memory.sh
+
+# Run monitoring during load test
+echo "Starting memory monitoring with load test..."
+./monitor-memory.sh 300 15 &  # 5 minutes, 15-second intervals
+MONITOR_PID=$!
+
+# Generate load during monitoring
+for i in {1..100}; do
+    curl -s -X POST http://localhost:8080/api/v1/objects/create > /dev/null
+    sleep 3
+done
+
+wait $MONITOR_PID
+echo "Memory monitoring completed"
+
    +

    Step 3: Alerting Thresholds

    +
    # Create alerting configuration
+cat > memory-alerts.sh << 'EOF'
+#!/bin/bash
+# Memory alerting script
+
+HEAP_THRESHOLD=80  # Alert when heap usage > 80%
+OBJECT_THRESHOLD=9000  # Alert when objects > 9000
+
+check_memory_usage() {
+    HEAP_USED=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.used?tag=area:heap | grep -o '"value":[0-9]*' | grep -o '[0-9]*')
+    HEAP_MAX=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.max?tag=area:heap | grep -o '"value":[0-9]*' | grep -o '[0-9]*')
+
+    if [ -n "$HEAP_USED" ] && [ -n "$HEAP_MAX" ]; then
+        HEAP_PCT=$((HEAP_USED * 100 / HEAP_MAX))
+
+        if [ $HEAP_PCT -gt $HEAP_THRESHOLD ]; then
+            echo "ALERT: Heap usage at ${HEAP_PCT}% (threshold: ${HEAP_THRESHOLD}%)"
+            return 1
+        fi
+    fi
+
+    return 0
+}
+
+check_object_count() {
+    OBJECT_RESPONSE=$(curl -s -X POST http://localhost:8080/api/v1/objects/create)
+    OBJECT_COUNT=$(echo "$OBJECT_RESPONSE" | grep -o '[0-9]*$' || echo "0")
+
+    if [ "$OBJECT_COUNT" -gt $OBJECT_THRESHOLD ]; then
+        echo "ALERT: Object count at $OBJECT_COUNT (threshold: $OBJECT_THRESHOLD)"
+        return 1
+    fi
+
+    return 0
+}
+
+# Run checks
+echo "=== MEMORY ALERT CHECK ==="
+ALERTS=0
+
+if ! check_memory_usage; then
+    ALERTS=$((ALERTS + 1))
+fi
+
+if ! check_object_count; then
+    ALERTS=$((ALERTS + 1))
+fi
+
+if [ $ALERTS -eq 0 ]; then
+    echo "βœ… All memory metrics within normal ranges"
+else
+    echo "⚠️  $ALERTS alert(s) triggered"
+fi
+
+exit $ALERTS
+EOF
+chmod +x memory-alerts.sh
+
+# Test alerting
+./memory-alerts.sh
+
    +
    +

    🎯 Module 4 Assessment

    +

    Implementation Validation Checklist

    +

    βœ… Emergency Response Completed:
    +- [ ] Successfully changed configuration to coco=false
    +- [ ] Verified NoCocoController is now active
    +- [ ] Confirmed bounds checking is working (MAX_OBJECTS limit)
    +- [ ] Validated thread pool management is operational
    +- [ ] Application remains stable and responsive

    +

    βœ… Code Pattern Understanding:
    +- [ ] Identified bounded collection implementation
    +- [ ] Understood shared thread pool lifecycle management
    +- [ ] Recognized @PreDestroy cleanup pattern
    +- [ ] Analyzed thread safety improvements
    +- [ ] Documented key differences between implementations

    +

    βœ… Monitoring and Validation:
    +- [ ] Generated post-fix profiling data
    +- [ ] Completed sustained load testing (10+ minutes)
    +- [ ] Implemented memory usage monitoring
    +- [ ] Created alerting thresholds and scripts
    +- [ ] Documented baseline metrics for comparison

    +

    βœ… Production Readiness:
    +- [ ] Validated fixes under realistic load conditions
    +- [ ] Established ongoing monitoring capabilities
    +- [ ] Created alerting for early problem detection
    +- [ ] Documented implementation for team knowledge transfer

    +

    🎯 Advanced Challenge: Custom Resource Management Pattern

    +

    Challenge: Implement your own resource management pattern following the principles learned

    +

    Scenario: Create a custom cache implementation that prevents memory leaks

    +

    Requirements:

    +
    // Implement this interface following NoCocoController patterns
+public class SafeCache<K, V> {
+    private static final int MAX_CACHE_SIZE = 1000;
+    private final Map<K, V> cache = /* your implementation */;
+
+    // TODO: Implement bounded put method
+    public V put(K key, V value) {
+        // Your bounds-checking implementation
+    }
+
+    // TODO: Implement cleanup method
+    @PreDestroy
+    public void cleanup() {
+        // Your resource cleanup implementation
+    }
+}
+
    +

    Success Criteria:
    +- [ ] Implements bounds checking to prevent unbounded growth
    +- [ ] Provides graceful handling when limits are reached
    +- [ ] Includes proper cleanup lifecycle management
    +- [ ] Thread-safe for concurrent access
    +- [ ] Includes monitoring/observability features

    +
    +

    πŸš€ Transition to Module 5

    +

    Fantastic implementation work! You've successfully:
    +- βœ… Applied the immediate configuration fix to eliminate memory leaks
    +- βœ… Understood and analyzed the resource management patterns
    +- βœ… Validated fixes through comprehensive testing
    +- βœ… Implemented monitoring and alerting infrastructure
    +- βœ… Demonstrated production-ready resource lifecycle management

    +

    What's Next?

    +

    In Module 5: Validation and Comparison, we'll focus on:
    +- Using @164-java-profiling-compare to rigorously validate improvements
    +- Generating before/after profiling comparisons
    +- Creating quantitative evidence of memory leak resolution
    +- Documenting the complete success story with measurable results

    +

    πŸ’‘ Key Takeaway

    +

    "The best fixes are not just functional - they're observable, maintainable, and educational. By understanding the patterns in NoCocoController, you've learned enterprise-grade resource management that applies far beyond this demo!"

    +

    Ready to prove your fixes work with rigorous before/after analysis? Let's complete the journey in Module 5! πŸ“Š

    + + +
    +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/courses/profile-memory-leak/module-5-validation.html b/docs/courses/profile-memory-leak/module-5-validation.html new file mode 100644 index 00000000..1019f2f8 --- /dev/null +++ b/docs/courses/profile-memory-leak/module-5-validation.html @@ -0,0 +1,722 @@ + + + + + + + + Module 5: Validation and Comparison - Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + + + +
    + + +
    +
    +
    +
    +
    +

    Module 5: Validation and Comparison

    +
    +
    +
    +
    +
    +
    + + +
    +
    +
    +
    + +
    + + 2025-09-17 +   + + Juan Antonio BreΓ±a Moral +   + + Version 0.11.0-SNAPSHOT +
    +   + + java + profiling + memory-leak + validation + comparison + before-after +
    +
    +
    + +

    Rigorous Before/After Analysis using @164-java-profiling-compare

    +

    ⏱️ Duration: 1 hour
    +🎯 Learning Objectives:
    +- Master the @164-java-profiling-compare system prompt for rigorous validation
    +- Generate comprehensive before/after profiling comparisons
    +- Create quantitative evidence of memory leak resolution
    +- Document measurable performance improvements
    +- Establish ongoing monitoring strategies for production deployment

    +
    +

    🎯 The Validation Framework

    +

    Understanding @164-java-profiling-compare Methodology

    +

    The comparison system prompt provides a rigorous framework for validating performance improvements:

    +
    Baseline Data β†’ Implementation β†’ Post-Fix Data β†’ Comparative Analysis β†’ Quantified Results
+
    +

    Key Principles:
    +1. Controlled Conditions: Identical test scenarios for accurate comparison
    +2. Quantitative Metrics: Measurable improvements with specific numbers
    +3. Visual Evidence: Side-by-side flamegraph analysis
    +4. Regression Detection: Identify any unintended performance impacts
    +5. Success Validation: Confirm optimization goals were achieved

    +

    πŸ’‘ Learning Insight

    +

    Effective performance validation requires the same rigor as scientific experiments - controlled conditions, reproducible results, and quantifiable outcomes. This module teaches you to think like a performance scientist!

    +
    +

    πŸ“Š Step 1: Baseline vs Post-Fix Data Collection

    +

    🎯 Practical Exercise 1: Generating Post-Fix Profiling Data

    +

    Since you've implemented the fixes in Module 4, let's generate comprehensive post-fix data:

    +
    cd ./cursor-rules-java/examples/spring-boot-memory-leak-demo
+
+# Verify we're running with fixes enabled
+echo "=== VERIFYING FIX STATUS ==="
+curl -s http://localhost:8080/actuator/env/coco | grep -E '"value"|"name"'
+
+# Ensure application is stable
+sleep 10
+curl -s http://localhost:8080/actuator/health
+
    +

    Generate Comprehensive Post-Fix Profiling Reports

    +
    cd profiler/scripts
+
+echo "=== GENERATING POST-FIX PROFILING DATA ==="
+echo "This will take approximately 6.5 minutes for complete analysis..."
+
+# Generate the complete memory analysis workflow (same as baseline)
+./profile-java-process.sh
+# Select: 9. Complete Memory Analysis Workflow
+
+# In another terminal, generate identical load pattern as baseline
+cd ./cursor-rules-java/examples/spring-boot-memory-leak-demo
+
+# Create load script that matches baseline conditions
+cat > post-fix-load.sh << 'EOF'
+#!/bin/bash
+echo "=== POST-FIX LOAD GENERATION ==="
+echo "Phase 1: Baseline load (30s)"
+timeout 30s bash -c 'while true; do curl -s -X POST http://localhost:8080/api/v1/objects/create > /dev/null; sleep 1; done' &
+
+echo "Phase 2: Detailed analysis load (60s)"
+sleep 30
+timeout 60s bash -c 'while true; do curl -s -X POST http://localhost:8080/api/v1/objects/create > /dev/null; curl -s -X POST http://localhost:8080/api/v1/threads/create > /dev/null; sleep 0.5; done' &
+
+echo "Phase 3: Leak detection load (5min)"
+sleep 90
+timeout 300s bash -c 'while true; do curl -s -X POST http://localhost:8080/api/v1/objects/create > /dev/null; sleep 0.3; done' &
+
+wait
+echo "All post-fix load phases completed"
+EOF
+chmod +x post-fix-load.sh
+
+# Execute the load generation
+./post-fix-load.sh
+
    +

    Organize Results for Comparison

    +
    # Create comparison workspace
+mkdir -p profiler/comparison-analysis
+cd profiler/comparison-analysis
+
+# Organize baseline reports (from Module 2)
+echo "=== ORGANIZING BASELINE REPORTS ==="
+mkdir -p baseline post-fix
+
+# Copy baseline reports (look for older timestamps)
+cp ../results/memory-baseline-*.html baseline/ 2>/dev/null || echo "No baseline reports found"
+cp ../results/memory-leak-*.html baseline/ 2>/dev/null || echo "No leak detection reports found"
+cp ../results/allocation-flamegraph-*.html baseline/ 2>/dev/null || echo "No allocation reports found"
+
+# Copy post-fix reports (look for recent timestamps)
+RECENT_DATE=$(date +%Y%m%d)
+cp ../results/memory-baseline-${RECENT_DATE}*.html post-fix/ 2>/dev/null || echo "No recent baseline reports found"
+cp ../results/memory-leak-*${RECENT_DATE}*.html post-fix/ 2>/dev/null || echo "No recent leak detection reports found"
+
+# Create inventory
+echo "=== COMPARISON INVENTORY ==="
+echo "Baseline reports: $(ls baseline/ 2>/dev/null | wc -l)"
+echo "Post-fix reports: $(ls post-fix/ 2>/dev/null | wc -l)"
+
+ls -la baseline/ post-fix/
+
    +
    +

    πŸ” Step 2: Side-by-Side Flamegraph Analysis

    +

    🎯 Practical Exercise 2: Visual Comparison Analysis

    +

    Open Reports for Side-by-Side Comparison

    +
    # Find the most relevant comparison files
+BASELINE_LEAK=$(ls baseline/memory-leak-*.html 2>/dev/null | head -1)
+POSTFIX_LEAK=$(ls post-fix/memory-leak-*.html 2>/dev/null | head -1)
+
+if [ -n "$BASELINE_LEAK" ] && [ -n "$POSTFIX_LEAK" ]; then
+    echo "Opening flamegraphs for comparison:"
+    echo "Baseline: $BASELINE_LEAK"
+    echo "Post-fix: $POSTFIX_LEAK"
+
+    # macOS
+    if [[ "$OSTYPE" == "darwin"* ]]; then
+        open "$BASELINE_LEAK"
+        sleep 2
+        open "$POSTFIX_LEAK"
+    # Linux
+    else
+        xdg-open "$BASELINE_LEAK" &
+        sleep 2
+        xdg-open "$POSTFIX_LEAK" &
+    fi
+else
+    echo "Missing comparison files. Ensure you have both baseline and post-fix reports."
+fi
+
    +

    Systematic Visual Analysis Framework

    +
    # Create visual comparison template
+cat > visual-comparison-analysis.md << 'EOF'
+# Visual Flamegraph Comparison Analysis
+
+## Report Information
+- **Baseline Report**: [filename]
+- **Post-Fix Report**: [filename]
+- **Analysis Date**: [date]
+- **Load Conditions**: [identical/different - describe]
+
+## Visual Comparison Metrics
+
+### Canvas Characteristics
+| Metric | Baseline | Post-Fix | Change | Improvement |
+|--------|----------|----------|--------|-------------|
+| Canvas Height (px) | [measure] | [measure] | [calculate] | [better/worse/same] |
+| Canvas Width (px) | [measure] | [measure] | [calculate] | [better/worse/same] |
+| Visual Complexity | [high/med/low] | [high/med/low] | [describe] | [better/worse/same] |
+
+### Stack Depth Analysis
+| Metric | Baseline | Post-Fix | Change | Improvement |
+|--------|----------|----------|--------|-------------|
+| Maximum Stack Depth | [count] | [count] | [calculate] | [better/worse/same] |
+| Average Stack Depth | [estimate] | [estimate] | [calculate] | [better/worse/same] |
+| Complex Stack Patterns | [count] | [count] | [calculate] | [better/worse/same] |
+
+### Method-Level Patterns
+| Method/Pattern | Baseline Width | Post-Fix Width | Change | Notes |
+|----------------|----------------|----------------|--------|-------|
+| CocoController.createObject | [wide/narrow/absent] | [wide/narrow/absent] | [describe] | [should be absent in post-fix] |
+| NoCocoController.createObject | [absent] | [wide/narrow/absent] | [describe] | [should be present in post-fix] |
+| ArrayList.add (unbounded) | [wide/narrow/absent] | [wide/narrow/absent] | [describe] | [should be reduced/absent] |
+| Bounds checking logic | [absent] | [narrow/wide/absent] | [describe] | [should be present in post-fix] |
+
+## Key Visual Differences
+### Memory Leak Indicators (Should be RESOLVED)
+- [ ] Continuous allocation patterns: [resolved/still present]
+- [ ] Growing stack complexity: [resolved/still present]
+- [ ] Unbounded collection growth: [resolved/still present]
+- [ ] Thread pool creation patterns: [resolved/still present]
+
+### Positive Changes (Should be PRESENT)
+- [ ] Bounds checking logic visible: [present/absent]
+- [ ] Shared resource patterns: [present/absent]
+- [ ] Cleanup/lifecycle patterns: [present/absent]
+- [ ] Error handling paths: [present/absent]
+
+## Overall Assessment
+- **Memory Leak Resolution**: [Complete/Partial/Failed]
+- **Performance Impact**: [Improved/Neutral/Degraded]
+- **Pattern Quality**: [Better/Same/Worse]
+- **Confidence Level**: [High/Medium/Low]
+
+## Recommendations
+1. [Next action item 1]
+2. [Next action item 2]
+3. [Next action item 3]
+EOF
+
+echo "Visual comparison template created. Fill in with your observations."
+
    +
    +

    πŸ“ˆ Step 3: Quantitative Metrics Extraction

    +

    🎯 Practical Exercise 3: Measurable Improvement Analysis

    +

    Extract Quantitative Data from Reports

    +
    # Create measurement extraction script
+cat > extract-metrics.sh << 'EOF'
+#!/bin/bash
+echo "=== QUANTITATIVE METRICS EXTRACTION ==="
+
+extract_metrics() {
+    local file="$1"
+    local label="$2"
+
+    if [ ! -f "$file" ]; then
+        echo "$label: File not found"
+        return
+    fi
+
+    echo "=== $label ==="
+    echo "File: $(basename "$file")"
+    echo "Size: $(wc -c < "$file") bytes"
+    echo "Generated: $(stat -c %y "$file" 2>/dev/null || stat -f %Sm "$file")"
+
+    # Extract technical metrics from HTML
+    local height=$(grep -o 'height="[0-9]*"' "$file" | head -1 | grep -o '[0-9]*')
+    local width=$(grep -o 'width="[0-9]*"' "$file" | head -1 | grep -o '[0-9]*')
+    local frames=$(grep -c 'class="func_g"' "$file")
+    local texts=$(grep -c '<text' "$file")
+
+    echo "Canvas Height: ${height:-unknown} pixels"
+    echo "Canvas Width: ${width:-unknown} pixels"
+    echo "Stack Frames: $frames elements"
+    echo "Text Labels: $texts labels"
+
+    # Estimate complexity score
+    if [ -n "$frames" ]; then
+        if [ "$frames" -gt 1000 ]; then
+            echo "Complexity Score: HIGH ($frames frames)"
+        elif [ "$frames" -gt 500 ]; then
+            echo "Complexity Score: MEDIUM ($frames frames)"
+        else
+            echo "Complexity Score: LOW ($frames frames)"
+        fi
+    fi
+
+    echo "---"
+}
+
+# Extract metrics from baseline and post-fix reports
+for baseline_file in baseline/*.html; do
+    if [ -f "$baseline_file" ]; then
+        extract_metrics "$baseline_file" "BASELINE - $(basename "$baseline_file")"
+    fi
+done
+
+for postfix_file in post-fix/*.html; do
+    if [ -f "$postfix_file" ]; then
+        extract_metrics "$postfix_file" "POST-FIX - $(basename "$postfix_file")"
+    fi
+done
+EOF
+chmod +x extract-metrics.sh
+
+# Run metrics extraction
+./extract-metrics.sh > metrics-comparison.txt
+cat metrics-comparison.txt
+
    +

    Calculate Improvement Percentages

    +
    # Create improvement calculation script
+cat > calculate-improvements.sh << 'EOF'
+#!/bin/bash
+echo "=== IMPROVEMENT CALCULATIONS ==="
+
+# Function to calculate percentage change
+calc_improvement() {
+    local baseline="$1"
+    local postfix="$2"
+    local metric_name="$3"
+
+    if [ -z "$baseline" ] || [ -z "$postfix" ] || [ "$baseline" -eq 0 ]; then
+        echo "$metric_name: Cannot calculate (missing data)"
+        return
+    fi
+
+    local change=$((postfix - baseline))
+    local percent=$((change * 100 / baseline))
+
+    if [ $change -lt 0 ]; then
+        echo "$metric_name: IMPROVED by ${percent#-}% (${baseline} β†’ ${postfix})"
+    elif [ $change -gt 0 ]; then
+        echo "$metric_name: INCREASED by ${percent}% (${baseline} β†’ ${postfix})"
+    else
+        echo "$metric_name: NO CHANGE (${baseline})"
+    fi
+}
+
+# Example calculations (you'll need to fill in actual values)
+echo "Fill in the actual values from your metrics-comparison.txt:"
+echo ""
+echo "# Example calculations:"
+echo "# calc_improvement 800 400 'Canvas Height'"
+echo "# calc_improvement 1200 600 'Stack Frames'"
+echo "# calc_improvement 50000 25000 'File Size'"
+
+# Template for your calculations
+cat << 'TEMPLATE'
+# Replace these example values with your actual measurements:
+
+# Canvas Height comparison
+# calc_improvement [baseline_height] [postfix_height] "Canvas Height"
+
+# Stack Frames comparison
+# calc_improvement [baseline_frames] [postfix_frames] "Stack Frames"
+
+# File Size comparison
+# calc_improvement [baseline_size] [postfix_size] "File Size"
+
+TEMPLATE
+EOF
+chmod +x calculate-improvements.sh
+
+./calculate-improvements.sh
+
    +
    +

    πŸ“‹ Step 4: Creating Comparison Documentation

    +

    Following @164-java-profiling-compare Template

    +
    # Create comprehensive comparison analysis document
+DATE_SUFFIX=$(date +%Y%m%d)
+cat > profiling-comparison-analysis-${DATE_SUFFIX}.md << 'EOF'
+# Profiling Comparison Analysis - [DATE]
+
+## Executive Summary
+- **Refactoring Objective**: Eliminate memory leaks in Spring Boot demo application
+- **Overall Result**: [SUCCESS/PARTIAL/FAILED]
+- **Key Improvements**:
+  - Memory leak patterns eliminated
+  - Resource lifecycle management implemented
+  - Application stability under load confirmed
+  - [Add specific improvements based on your analysis]
+
+## Methodology
+- **Baseline Date**: [Date of original profiling from Module 2]
+- **Post-Refactoring Date**: [Today's date]
+- **Test Scenarios**: Identical load patterns using coordinated JMeter testing
+- **Duration**: Complete Memory Analysis Workflow (6.5 minutes total)
+- **Load Pattern**: 30s baseline + 60s detailed + 300s leak detection
+
+## Before/After Metrics
+| Metric | Before (Baseline) | After (Post-Fix) | Improvement |
+|--------|-------------------|------------------|-------------|
+| Canvas Height (pixels) | [your measurement] | [your measurement] | [calculate %] |
+| Stack Frames (count) | [your measurement] | [your measurement] | [calculate %] |
+| File Size (bytes) | [your measurement] | [your measurement] | [calculate %] |
+| Visual Complexity | [HIGH/MED/LOW] | [HIGH/MED/LOW] | [better/worse/same] |
+| Memory Growth Pattern | Continuous growth | Bounded/stable | βœ… RESOLVED |
+| Thread Pool Behavior | New pools per request | Shared managed pool | βœ… RESOLVED |
+
+## Key Findings
+
+### βœ… Resolved Issues
+- [x] **Unbounded Collection Growth**: ArrayList.add patterns eliminated from flamegraphs
+- [x] **Thread Pool Leaks**: ExecutorService creation patterns no longer visible
+- [x] **Memory Accumulation**: Long-term allocation patterns stabilized
+- [x] **Resource Cleanup**: @PreDestroy patterns now visible in profiling data
+
+### πŸ” Performance Characteristics
+- [x] **Bounds Checking**: New error handling paths visible in post-fix flamegraphs
+- [x] **Shared Resources**: Thread pool management patterns consolidated
+- [x] **Lifecycle Management**: Cleanup and shutdown patterns implemented
+- [x] **Error Handling**: Graceful degradation under load limits
+
+### πŸ“Š Quantitative Improvements
+- **Memory Leak Elimination**: [X]% reduction in continuous allocation patterns
+- **Stack Complexity**: [X]% reduction in average stack depth
+- **Resource Efficiency**: [X]% improvement in thread management patterns
+- **Stability**: Application maintains consistent performance under sustained load
+
+## Visual Evidence
+- **Baseline Reports**: `baseline/memory-leak-*.html`
+- **After Reports**: `post-fix/memory-leak-*.html`
+- **Key Differences**:
+  - CocoController allocation patterns absent in post-fix reports
+  - NoCocoController bounds checking visible in post-fix reports
+  - Thread pool creation patterns eliminated
+  - Error handling paths clearly visible
+
+## Load Testing Validation
+- **Sustained Load Test**: 10+ minutes at 3 concurrent users
+- **Memory Stability**: No continuous growth patterns observed
+- **Response Time**: Maintained under 100ms for all endpoints
+- **Error Handling**: Graceful degradation when limits reached
+- **Resource Usage**: CPU and memory usage remained stable
+
+## Production Readiness Assessment
+- [x] **Performance targets met**: Memory leaks eliminated
+- [x] **No regressions introduced**: Application functionality maintained
+- [x] **Load testing completed**: Sustained load validation successful
+- [x] **Monitoring configured**: Memory alerts and thresholds established
+
+## Recommendations
+1. **Deploy to Production**: Fixes validated and ready for production deployment
+2. **Enable Monitoring**: Activate memory usage alerts and dashboards
+3. **Update Documentation**: Share learnings with development team
+4. **Continuous Monitoring**: Implement ongoing profiling in CI/CD pipeline
+
+## Success Validation
+- **Technical Success**: βœ… All memory leak patterns eliminated
+- **Performance Success**: βœ… Application stability maintained under load
+- **Monitoring Success**: βœ… Alerting and monitoring infrastructure operational
+- **Knowledge Transfer**: βœ… Team equipped with profiling and analysis skills
+
+## Risk Assessment
+- **Deployment Risk**: LOW - Configuration change with proven results
+- **Performance Risk**: LOW - No performance degradation observed
+- **Regression Risk**: LOW - Comprehensive testing completed
+- **Operational Risk**: LOW - Monitoring and alerting in place
+EOF
+
+echo "Comparison analysis document created: profiling-comparison-analysis-${DATE_SUFFIX}.md"
+echo "Please fill in the specific measurements from your analysis."
+
    +

    Create Final Results Summary

    +
    # Create final results summary
+cat > profiling-final-results-${DATE_SUFFIX}.md << 'EOF'
+# Profiling Final Results - [DATE]
+
+## Summary
+- **Analysis Date**: [Today's date]
+- **Performance Objective**: Eliminate memory leaks in Spring Boot demo application
+- **Status**: βœ… COMPLETE - All objectives achieved
+- **Implementation**: coco=false configuration successfully deployed
+
+## Key Metrics Summary
+| Performance Area | Before | After | Improvement |
+|---|---|----|----|
+| Memory Leaks | Active leaks detected | No leaks detected | βœ… 100% resolved |
+| Memory Growth | Continuous unbounded | Stable bounded | βœ… Stabilized |
+| Thread Management | New pools per request | Shared managed pool | βœ… 90%+ efficiency |
+| Resource Cleanup | No cleanup logic | @PreDestroy implemented | βœ… Complete lifecycle |
+| Error Handling | No bounds checking | Graceful degradation | βœ… Production ready |
+
+## Critical Issues Resolved
+1. **Unbounded Collection Growth**: Implemented MAX_OBJECTS bounds with graceful error handling
+2. **Thread Pool Resource Leaks**: Replaced per-request pools with shared managed ExecutorService
+3. **Missing Resource Cleanup**: Added @PreDestroy lifecycle management with proper shutdown
+4. **Lack of Monitoring**: Established memory usage monitoring and alerting infrastructure
+
+## Technical Achievements
+- **Configuration Management**: Demonstrated feature flag pattern (coco=true/false)
+- **Resource Lifecycle**: Implemented enterprise-grade resource management patterns
+- **Performance Validation**: Rigorous before/after comparison with quantitative evidence
+- **Monitoring Infrastructure**: Comprehensive memory monitoring and alerting system
+- **Knowledge Transfer**: Complete documentation and team education
+
+## Production Readiness
+- [x] **Performance targets met**: All memory leak patterns eliminated
+- [x] **No regressions introduced**: Application functionality fully maintained
+- [x] **Load testing completed**: Sustained load validation over 10+ minutes
+- [x] **Monitoring alerts configured**: Memory usage thresholds and alerting operational
+- [x] **Documentation complete**: Full analysis and implementation documentation
+- [x] **Team knowledge transfer**: Profiling skills and patterns shared
+
+## Business Impact
+- **Risk Mitigation**: Eliminated potential production outages from memory exhaustion
+- **Performance**: Improved application stability and resource efficiency
+- **Cost**: Minimal development investment with maximum impact
+- **Timeline**: Issue identified, analyzed, and resolved within course duration
+- **Knowledge**: Team equipped with systematic performance analysis skills
+
+## Lessons Learned
+- **Systematic Approach**: Structured profiling methodology produces reliable results
+- **Evidence-Based**: Quantitative analysis enables confident decision-making
+- **Pattern Recognition**: Understanding resource lifecycle patterns prevents similar issues
+- **Monitoring Importance**: Proactive monitoring prevents problems before they impact users
+- **Documentation Value**: Thorough documentation enables knowledge sharing and future reference
+
+## Next Steps
+1. **Production Deployment**: Deploy coco=false configuration to production environment
+2. **Monitoring Activation**: Enable memory usage alerts and dashboards in production
+3. **Process Integration**: Add profiling validation to CI/CD pipeline
+4. **Team Training**: Share profiling techniques and patterns with broader development team
+5. **Continuous Improvement**: Establish regular performance review and optimization cycles
+
+## Related Documents
+- **Analysis**: `profiling-comparison-analysis-[DATE].md`
+- **Baseline Reports**: `baseline/*.html`
+- **Post-Fix Reports**: `post-fix/*.html`
+- **Monitoring Scripts**: `monitor-memory.sh`, `memory-alerts.sh`
+
+---
+
+**πŸŽ‰ COURSE COMPLETION: Congratulations on mastering Java memory leak detection and resolution using systematic profiling techniques and system prompts!**
+EOF
+
+echo "Final results summary created: profiling-final-results-${DATE_SUFFIX}.md"
+
    +
    +

    🎯 Module 5 Assessment and Course Completion

    +

    Final Validation Checklist

    +

    βœ… Comparative Analysis Mastery:
    +- [ ] Generated post-fix profiling data under identical conditions
    +- [ ] Performed side-by-side flamegraph comparison
    +- [ ] Extracted quantitative metrics from before/after reports
    +- [ ] Calculated improvement percentages and impact measurements
    +- [ ] Created comprehensive comparison documentation

    +

    βœ… Evidence-Based Validation:
    +- [ ] Documented visual evidence of memory leak resolution
    +- [ ] Quantified performance improvements with specific metrics
    +- [ ] Validated fixes through sustained load testing
    +- [ ] Confirmed no performance regressions introduced
    +- [ ] Established ongoing monitoring and alerting

    +

    βœ… Professional Documentation:
    +- [ ] Created comparison analysis following @164-java-profiling-compare template
    +- [ ] Generated final results summary suitable for stakeholders
    +- [ ] Documented lessons learned and best practices
    +- [ ] Provided actionable recommendations for production deployment
    +- [ ] Established foundation for future performance optimization work

    +

    πŸ† Course Completion Achievement

    +

    Congratulations! You have successfully completed the "Java Memory Leak Detection Course - From Detection to Resolution using System Prompts"

    +

    Your Achievements:
    +- βœ… Module 1: Mastered memory leak foundations and detection setup
    +- βœ… Module 2: Became proficient with 21 profiling options and flamegraph interpretation
    +- βœ… Module 3: Applied systematic analysis and created evidence-based documentation
    +- βœ… Module 4: Implemented enterprise-grade resource management patterns
    +- βœ… Module 5: Validated improvements through rigorous comparative analysis

    +

    πŸŽ“ Skills Acquired

    +

    Technical Proficiency:
    +- async-profiler mastery with 21+ profiling options
    +- JFR analysis and interpretation
    +- Flamegraph visual analysis and pattern recognition
    +- JMeter load testing integration
    +- Memory monitoring and alerting setup

    +

    Analytical Skills:
    +- Systematic problem identification and categorization
    +- Impact/Effort prioritization frameworks
    +- Cross-correlation analysis techniques
    +- Evidence-based documentation
    +- Quantitative improvement measurement

    +

    Professional Competencies:
    +- Enterprise resource lifecycle management patterns
    +- Production-ready monitoring and alerting
    +- Stakeholder communication and reporting
    +- Knowledge transfer and team education
    +- Continuous improvement methodologies

    +
    +

    πŸ’‘ Final Reflection

    +

    Key Takeaways

    +
      +
    • Systematic Methodology: Structured approaches produce reliable, reproducible results
      • +
    • Evidence-Based Decisions: Quantitative analysis enables confident optimization choices
      • +
    • Pattern Recognition: Understanding resource lifecycle patterns prevents entire classes of issues
      • +
    • Continuous Learning: Performance optimization is an ongoing discipline requiring constant skill development
      • +
    +

    The Power of System Prompts

    +

    Through this course, you've experienced how system prompts (@161, @162, @164) provide:
    +- Structured Workflows: Consistent, repeatable processes
    +- Best Practices: Proven methodologies
    +- Knowledge Transfer: Systematic approaches that can be taught and shared
    +- Quality Assurance: Built-in validation and verification steps

    +

    πŸŽ‰ You've not just learned to fix memory leaks - you've mastered a systematic approach to performance optimization that will serve you throughout your career!

    +

    Thank you for completing this comprehensive course. Your dedication to learning systematic performance optimization techniques will make you a more effective developer and a valuable team member. Keep profiling, keep learning, and keep optimizing! Return to the beginning πŸš€

    + + +
    +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/css/main.css b/docs/css/main.css index 3e584465..d44eabd6 100644 --- a/docs/css/main.css +++ b/docs/css/main.css @@ -233,6 +233,9 @@ img { } .navbar-custom .nav .navlinks-children { position: absolute; + min-width: 200px; + width: max-content; + white-space: nowrap; } .navbar-custom .nav .navlinks-container .navlinks-children a { padding-left: 10px; diff --git a/docs/feed.xml b/docs/feed.xml index 1f681c14..bf83d908 100644 --- a/docs/feed.xml +++ b/docs/feed.xml @@ -2,7 +2,7 @@ https://jabrena.github.io/cursor-rules-java/ Cursor Rules for Java - 2025-09-16T13:14:58+0200 + 2025-09-17T18:14:20+0200 diff --git a/docs/index.html b/docs/index.html index aa0ac715..29232dc3 100644 --- a/docs/index.html +++ b/docs/index.html @@ -44,6 +44,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -109,6 +110,9 @@

    What's new i

    2025-09-05 +   + + Juan Antonio BreΓ±a Moral   @@ -134,6 +138,9 @@

    What's new in

    2025-07-23 +   + + Juan Antonio BreΓ±a Moral   @@ -161,6 +168,9 @@

    The Thr

    2025-07-20 +   + + Juan Antonio BreΓ±a Moral   @@ -186,6 +196,9 @@

    What's new in

    2025-07-12 +   + + Juan Antonio BreΓ±a Moral   diff --git a/docs/tags.html b/docs/tags.html index 584db17f..0e345174 100644 --- a/docs/tags.html +++ b/docs/tags.html @@ -43,6 +43,7 @@ Courses

    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -91,6 +92,10 @@

    Tags

    + + evidence + 1 + crtp 1 @@ -99,28 +104,24 @@

    Tags

    records 1     + + async-profiler + 2 + wildcards 1 - - foundations - 1 - blog 4 - - sealed-types - 1 - - - type-erasure + + flamegraph 1 - - serialization + + jmeter 1 @@ -139,20 +140,16 @@

    Tags

    assessment 1     - - help - 1 - java - 7 + 13 api-design 1 - - performance + + refactoring 1 @@ -163,24 +160,88 @@

    Tags

    advanced-patterns 2     - - variance - 1 - faq 1 - - support + + before-after 1 + + validation + 3 + type-safety 2 - - validation + + detection + 1 + + + memory-leak + 6 + + + comparison + 1 + + + implementation + 1 + + + documentation + 1 + + + foundations + 2 + + + analysis + 1 + + + sealed-types + 1 + + + type-erasure + 1 + + + system-prompts + 1 + + + serialization + 1 + + + help + 1 + + + performance + 2 + + + profiling + 6 + + + variance + 1 + + + setup + 1 + + + support 1 diff --git a/docs/tags/advanced-patterns.html b/docs/tags/advanced-patterns.html index 71f83ba9..55d04b4c 100644 --- a/docs/tags/advanced-patterns.html +++ b/docs/tags/advanced-patterns.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/analysis.html b/docs/tags/analysis.html new file mode 100644 index 00000000..ff8480df --- /dev/null +++ b/docs/tags/analysis.html @@ -0,0 +1,174 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #analysis

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 3: Analysis and Evidence Collection

    + +

    + +   + + java + profiling + memory-leak + analysis + evidence + documentation + +

    + +
    +
    + Systematic Analysis using @162-java-profiling-analyze +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Master the systematic analysis framework from @162-java-profiling-analyze +- Learn to categorize and prioritize performance issues using Impact/Effort scoring +- Create structured documentation following professional templates +- Develop cross-correlation analysis skills for multiple profiling results +... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/api-design.html b/docs/tags/api-design.html index 4c72be58..37c48778 100644 --- a/docs/tags/api-design.html +++ b/docs/tags/api-design.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/assessment.html b/docs/tags/assessment.html index d5342fce..2952925b 100644 --- a/docs/tags/assessment.html +++ b/docs/tags/assessment.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/async-profiler.html b/docs/tags/async-profiler.html new file mode 100644 index 00000000..b0becbd3 --- /dev/null +++ b/docs/tags/async-profiler.html @@ -0,0 +1,203 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #async-profiler

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 2: Hands-on Profiling with System Prompts

    + +

    + +   + + java + profiling + memory-leak + async-profiler + flamegraph + jmeter + +

    + +
    +
    + Mastering the Interactive Profiling Script and Evidence Collection +⏱️ Duration: 3 hours +🎯 Learning Objectives: +- Master the @161-java-profiling-detect system prompt and its 21 profiling options +- Learn problem-driven profiling strategies for different performance issues +- Understand flamegraph interpretation and visual analysis techniques +- Generate comprehensive profiling evidence under realistic... +

    + [Read More] +
    +
    +
    +
    +

    Mastering Java Memory Leak Detection - Complete Learning Path

    + +

    + +   + + java + profiling + memory-leak + performance + system-prompts + async-profiler + +

    + +
    +
    + 🎯 Master Java memory leak detection through hands-on profiling with the Spring Boot memory leak demo + +πŸ“š Course Structure + +Module 1: Foundations - 2 hours (Focus: Memory leak theory and setup; Key learning: Understanding leak patterns; profiling infrastructure) +Module 2: Profiling - 3 hours (Focus: Hands-on profiling mastery; Key learning: 21 profiling options; flamegraph interpretation) +Module 3:... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/before-after.html b/docs/tags/before-after.html new file mode 100644 index 00000000..7669bf3a --- /dev/null +++ b/docs/tags/before-after.html @@ -0,0 +1,174 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #before-after

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 5: Validation and Comparison

    + +

    + +   + + java + profiling + memory-leak + validation + comparison + before-after + +

    + +
    +
    + Rigorous Before/After Analysis using @164-java-profiling-compare +⏱️ Duration: 1 hour +🎯 Learning Objectives: +- Master the @164-java-profiling-compare system prompt for rigorous validation +- Generate comprehensive before/after profiling comparisons +- Create quantitative evidence of memory leak resolution +- Document measurable performance improvements +- Establish ongoing monitoring strategies for pro... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/blog.html b/docs/tags/blog.html index b41400b6..dd63567e 100644 --- a/docs/tags/blog.html +++ b/docs/tags/blog.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -79,6 +80,9 @@

    What's ne

    2025-09-05 +   + + Juan Antonio BreΓ±a Moral   @@ -104,6 +108,9 @@

    What's new

    2025-07-23 +   + + Juan Antonio BreΓ±a Moral   @@ -131,6 +138,9 @@

    The

    2025-07-20 +   + + Juan Antonio BreΓ±a Moral   @@ -156,6 +166,9 @@

    What's new

    2025-07-12 +   + + Juan Antonio BreΓ±a Moral   diff --git a/docs/tags/comparison.html b/docs/tags/comparison.html new file mode 100644 index 00000000..ce923ebb --- /dev/null +++ b/docs/tags/comparison.html @@ -0,0 +1,174 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + +

     + +
    +
    +
    +
    +
    +

    #comparison

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 5: Validation and Comparison

    + +

    + +   + + java + profiling + memory-leak + validation + comparison + before-after + +

    + +
    +
    + Rigorous Before/After Analysis using @164-java-profiling-compare +⏱️ Duration: 1 hour +🎯 Learning Objectives: +- Master the @164-java-profiling-compare system prompt for rigorous validation +- Generate comprehensive before/after profiling comparisons +- Create quantitative evidence of memory leak resolution +- Document measurable performance improvements +- Establish ongoing monitoring strategies for pro... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/crtp.html b/docs/tags/crtp.html index 557111ac..9c658dac 100644 --- a/docs/tags/crtp.html +++ b/docs/tags/crtp.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/detection.html b/docs/tags/detection.html new file mode 100644 index 00000000..8997edb2 --- /dev/null +++ b/docs/tags/detection.html @@ -0,0 +1,174 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #detection

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 1: Memory Leak Foundations and Detection Setup

    + +

    + +   + + java + profiling + memory-leak + foundations + detection + setup + +

    + +
    +
    + Understanding Memory Leaks and Building Detection Infrastructure +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Understand what memory leaks are and why they're critical in Java applications +- Identify different types of memory leak patterns in enterprise applications +- Explore the Spring Boot memory leak demo architecture +- Set up automated profiling infrastructure using system prompts +- Understan... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/documentation.html b/docs/tags/documentation.html new file mode 100644 index 00000000..706ba3fc --- /dev/null +++ b/docs/tags/documentation.html @@ -0,0 +1,174 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #documentation

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 3: Analysis and Evidence Collection

    + +

    + +   + + java + profiling + memory-leak + analysis + evidence + documentation + +

    + +
    +
    + Systematic Analysis using @162-java-profiling-analyze +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Master the systematic analysis framework from @162-java-profiling-analyze +- Learn to categorize and prioritize performance issues using Impact/Effort scoring +- Create structured documentation following professional templates +- Develop cross-correlation analysis skills for multiple profiling results +... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/evidence.html b/docs/tags/evidence.html new file mode 100644 index 00000000..50b8e1a0 --- /dev/null +++ b/docs/tags/evidence.html @@ -0,0 +1,174 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #evidence

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 3: Analysis and Evidence Collection

    + +

    + +   + + java + profiling + memory-leak + analysis + evidence + documentation + +

    + +
    +
    + Systematic Analysis using @162-java-profiling-analyze +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Master the systematic analysis framework from @162-java-profiling-analyze +- Learn to categorize and prioritize performance issues using Impact/Effort scoring +- Create structured documentation following professional templates +- Develop cross-correlation analysis skills for multiple profiling results +... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/faq.html b/docs/tags/faq.html index acd93c68..a44a6589 100644 --- a/docs/tags/faq.html +++ b/docs/tags/faq.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -90,13 +91,13 @@

    Frequently As
    - ❓ Frequently Asked Questions -πŸ“š Course Content + πŸ“š Course Content Q: What Java version do I need for this course? A: The course is designed for Java 17+ (LTS), but most concepts work from Java 8+. Modern features like Records and sealed types require Java 14+ and Java 17+ respectively. Q: How long does it take to complete the course? A: The full course is designed for 12-15 hours: -- Quick Start: 2 hours (essentials o... +- Quick Start: 2 hours (essentials only) +- Comprehensive: 12-15 h...

    [Read More]
    diff --git a/docs/tags/flamegraph.html b/docs/tags/flamegraph.html new file mode 100644 index 00000000..4166b5e5 --- /dev/null +++ b/docs/tags/flamegraph.html @@ -0,0 +1,173 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #flamegraph

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 2: Hands-on Profiling with System Prompts

    + +

    + +   + + java + profiling + memory-leak + async-profiler + flamegraph + jmeter + +

    + +
    +
    + Mastering the Interactive Profiling Script and Evidence Collection +⏱️ Duration: 3 hours +🎯 Learning Objectives: +- Master the @161-java-profiling-detect system prompt and its 21 profiling options +- Learn problem-driven profiling strategies for different performance issues +- Understand flamegraph interpretation and visual analysis techniques +- Generate comprehensive profiling evidence under realistic... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/foundations.html b/docs/tags/foundations.html index 77241e9b..b81048d0 100644 --- a/docs/tags/foundations.html +++ b/docs/tags/foundations.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -74,6 +75,37 @@
    +

    Module 1: Memory Leak Foundations and Detection Setup

    + +

    + +   + + java + profiling + memory-leak + foundations + detection + setup + +

    + +
    +
    + Understanding Memory Leaks and Building Detection Infrastructure +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Understand what memory leaks are and why they're critical in Java applications +- Identify different types of memory leak patterns in enterprise applications +- Explore the Spring Boot memory leak demo architecture +- Set up automated profiling infrastructure using system prompts +- Understan... +

    + [Read More] +
    +
    +
    +

    Module 1: Foundations - Core Concepts and Type Safety

    diff --git a/docs/tags/generics.html b/docs/tags/generics.html index bcc61239..98f6be00 100644 --- a/docs/tags/generics.html +++ b/docs/tags/generics.html @@ -43,6 +43,7 @@ Courses

    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -265,13 +266,13 @@

    Frequently As
    - ❓ Frequently Asked Questions -πŸ“š Course Content + πŸ“š Course Content Q: What Java version do I need for this course? A: The course is designed for Java 17+ (LTS), but most concepts work from Java 8+. Modern features like Records and sealed types require Java 14+ and Java 17+ respectively. Q: How long does it take to complete the course? A: The full course is designed for 12-15 hours: -- Quick Start: 2 hours (essentials o... +- Quick Start: 2 hours (essentials only) +- Comprehensive: 12-15 h...

    [Read More]
    diff --git a/docs/tags/help.html b/docs/tags/help.html index a0ea4585..00a56afd 100644 --- a/docs/tags/help.html +++ b/docs/tags/help.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -90,13 +91,13 @@

    Frequently As
    - ❓ Frequently Asked Questions -πŸ“š Course Content + πŸ“š Course Content Q: What Java version do I need for this course? A: The course is designed for Java 17+ (LTS), but most concepts work from Java 8+. Modern features like Records and sealed types require Java 14+ and Java 17+ respectively. Q: How long does it take to complete the course? A: The full course is designed for 12-15 hours: -- Quick Start: 2 hours (essentials o... +- Quick Start: 2 hours (essentials only) +- Comprehensive: 12-15 h...

    [Read More]
    diff --git a/docs/tags/implementation.html b/docs/tags/implementation.html new file mode 100644 index 00000000..01947fb0 --- /dev/null +++ b/docs/tags/implementation.html @@ -0,0 +1,174 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #implementation

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 4: Refactoring and Solution Implementation

    + +

    + +   + + java + profiling + memory-leak + refactoring + implementation + validation + +

    + +
    +
    + Implementing Memory Leak Fixes and Validation +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Implement the prioritized solutions identified in Module 3 +- Understand the coco=false configuration pattern for immediate leak resolution +- Understand proper resource lifecycle management patterns +- Validate that fixes are correctly applied and effective +- Set up monitoring and alerting for ongoing protect... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/java.html b/docs/tags/java.html index ec83abd4..6a653c3f 100644 --- a/docs/tags/java.html +++ b/docs/tags/java.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -74,6 +75,190 @@
    +

    Module 3: Analysis and Evidence Collection

    + +

    + +   + + java + profiling + memory-leak + analysis + evidence + documentation + +

    + +
    +
    + Systematic Analysis using @162-java-profiling-analyze +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Master the systematic analysis framework from @162-java-profiling-analyze +- Learn to categorize and prioritize performance issues using Impact/Effort scoring +- Create structured documentation following professional templates +- Develop cross-correlation analysis skills for multiple profiling results +... +

    + [Read More] +
    +
    +
    +
    +

    Module 2: Hands-on Profiling with System Prompts

    + +

    + +   + + java + profiling + memory-leak + async-profiler + flamegraph + jmeter + +

    + +
    +
    + Mastering the Interactive Profiling Script and Evidence Collection +⏱️ Duration: 3 hours +🎯 Learning Objectives: +- Master the @161-java-profiling-detect system prompt and its 21 profiling options +- Learn problem-driven profiling strategies for different performance issues +- Understand flamegraph interpretation and visual analysis techniques +- Generate comprehensive profiling evidence under realistic... +

    + [Read More] +
    +
    +
    +
    +

    Module 1: Memory Leak Foundations and Detection Setup

    + +

    + +   + + java + profiling + memory-leak + foundations + detection + setup + +

    + +
    +
    + Understanding Memory Leaks and Building Detection Infrastructure +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Understand what memory leaks are and why they're critical in Java applications +- Identify different types of memory leak patterns in enterprise applications +- Explore the Spring Boot memory leak demo architecture +- Set up automated profiling infrastructure using system prompts +- Understan... +

    + [Read More] +
    +
    +
    +
    +

    Mastering Java Memory Leak Detection - Complete Learning Path

    + +

    + +   + + java + profiling + memory-leak + performance + system-prompts + async-profiler + +

    + +
    +
    + 🎯 Master Java memory leak detection through hands-on profiling with the Spring Boot memory leak demo + +πŸ“š Course Structure + +Module 1: Foundations - 2 hours (Focus: Memory leak theory and setup; Key learning: Understanding leak patterns; profiling infrastructure) +Module 2: Profiling - 3 hours (Focus: Hands-on profiling mastery; Key learning: 21 profiling options; flamegraph interpretation) +Module 3:... +

    + [Read More] +
    +
    +
    +
    +

    Module 5: Validation and Comparison

    + +

    + +   + + java + profiling + memory-leak + validation + comparison + before-after + +

    + +
    +
    + Rigorous Before/After Analysis using @164-java-profiling-compare +⏱️ Duration: 1 hour +🎯 Learning Objectives: +- Master the @164-java-profiling-compare system prompt for rigorous validation +- Generate comprehensive before/after profiling comparisons +- Create quantitative evidence of memory leak resolution +- Document measurable performance improvements +- Establish ongoing monitoring strategies for pro... +

    + [Read More] +
    +
    +
    +
    +

    Module 4: Refactoring and Solution Implementation

    + +

    + +   + + java + profiling + memory-leak + refactoring + implementation + validation + +

    + +
    +
    + Implementing Memory Leak Fixes and Validation +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Implement the prioritized solutions identified in Module 3 +- Understand the coco=false configuration pattern for immediate leak resolution +- Understand proper resource lifecycle management patterns +- Validate that fixes are correctly applied and effective +- Set up monitoring and alerting for ongoing protect... +

    + [Read More] +
    +
    +
    +

    Mastering Java Generics - From Type Safety to Advanced Patterns

    @@ -265,13 +450,13 @@

    Frequently As
    - ❓ Frequently Asked Questions -πŸ“š Course Content + πŸ“š Course Content Q: What Java version do I need for this course? A: The course is designed for Java 17+ (LTS), but most concepts work from Java 8+. Modern features like Records and sealed types require Java 14+ and Java 17+ respectively. Q: How long does it take to complete the course? A: The full course is designed for 12-15 hours: -- Quick Start: 2 hours (essentials o... +- Quick Start: 2 hours (essentials only) +- Comprehensive: 12-15 h...

    [Read More]
    diff --git a/docs/tags/jmeter.html b/docs/tags/jmeter.html new file mode 100644 index 00000000..117cdf6a --- /dev/null +++ b/docs/tags/jmeter.html @@ -0,0 +1,173 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #jmeter

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 2: Hands-on Profiling with System Prompts

    + +

    + +   + + java + profiling + memory-leak + async-profiler + flamegraph + jmeter + +

    + +
    +
    + Mastering the Interactive Profiling Script and Evidence Collection +⏱️ Duration: 3 hours +🎯 Learning Objectives: +- Master the @161-java-profiling-detect system prompt and its 21 profiling options +- Learn problem-driven profiling strategies for different performance issues +- Understand flamegraph interpretation and visual analysis techniques +- Generate comprehensive profiling evidence under realistic... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/memory-leak.html b/docs/tags/memory-leak.html new file mode 100644 index 00000000..05e15e3e --- /dev/null +++ b/docs/tags/memory-leak.html @@ -0,0 +1,327 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #memory-leak

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 3: Analysis and Evidence Collection

    + +

    + +   + + java + profiling + memory-leak + analysis + evidence + documentation + +

    + +
    +
    + Systematic Analysis using @162-java-profiling-analyze +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Master the systematic analysis framework from @162-java-profiling-analyze +- Learn to categorize and prioritize performance issues using Impact/Effort scoring +- Create structured documentation following professional templates +- Develop cross-correlation analysis skills for multiple profiling results +... +

    + [Read More] +
    +
    +
    +
    +

    Module 2: Hands-on Profiling with System Prompts

    + +

    + +   + + java + profiling + memory-leak + async-profiler + flamegraph + jmeter + +

    + +
    +
    + Mastering the Interactive Profiling Script and Evidence Collection +⏱️ Duration: 3 hours +🎯 Learning Objectives: +- Master the @161-java-profiling-detect system prompt and its 21 profiling options +- Learn problem-driven profiling strategies for different performance issues +- Understand flamegraph interpretation and visual analysis techniques +- Generate comprehensive profiling evidence under realistic... +

    + [Read More] +
    +
    +
    +
    +

    Module 1: Memory Leak Foundations and Detection Setup

    + +

    + +   + + java + profiling + memory-leak + foundations + detection + setup + +

    + +
    +
    + Understanding Memory Leaks and Building Detection Infrastructure +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Understand what memory leaks are and why they're critical in Java applications +- Identify different types of memory leak patterns in enterprise applications +- Explore the Spring Boot memory leak demo architecture +- Set up automated profiling infrastructure using system prompts +- Understan... +

    + [Read More] +
    +
    +
    +
    +

    Mastering Java Memory Leak Detection - Complete Learning Path

    + +

    + +   + + java + profiling + memory-leak + performance + system-prompts + async-profiler + +

    + +
    +
    + 🎯 Master Java memory leak detection through hands-on profiling with the Spring Boot memory leak demo + +πŸ“š Course Structure + +Module 1: Foundations - 2 hours (Focus: Memory leak theory and setup; Key learning: Understanding leak patterns; profiling infrastructure) +Module 2: Profiling - 3 hours (Focus: Hands-on profiling mastery; Key learning: 21 profiling options; flamegraph interpretation) +Module 3:... +

    + [Read More] +
    +
    +
    +
    +

    Module 5: Validation and Comparison

    + +

    + +   + + java + profiling + memory-leak + validation + comparison + before-after + +

    + +
    +
    + Rigorous Before/After Analysis using @164-java-profiling-compare +⏱️ Duration: 1 hour +🎯 Learning Objectives: +- Master the @164-java-profiling-compare system prompt for rigorous validation +- Generate comprehensive before/after profiling comparisons +- Create quantitative evidence of memory leak resolution +- Document measurable performance improvements +- Establish ongoing monitoring strategies for pro... +

    + [Read More] +
    +
    +
    +
    +

    Module 4: Refactoring and Solution Implementation

    + +

    + +   + + java + profiling + memory-leak + refactoring + implementation + validation + +

    + +
    +
    + Implementing Memory Leak Fixes and Validation +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Implement the prioritized solutions identified in Module 3 +- Understand the coco=false configuration pattern for immediate leak resolution +- Understand proper resource lifecycle management patterns +- Validate that fixes are correctly applied and effective +- Set up monitoring and alerting for ongoing protect... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/pecs.html b/docs/tags/pecs.html index ebb7794f..48fbbe1e 100644 --- a/docs/tags/pecs.html +++ b/docs/tags/pecs.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/performance.html b/docs/tags/performance.html index 78cd32d6..bd43d1ff 100644 --- a/docs/tags/performance.html +++ b/docs/tags/performance.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -74,6 +75,36 @@
    +

    Mastering Java Memory Leak Detection - Complete Learning Path

    + +

    + +   + + java + profiling + memory-leak + performance + system-prompts + async-profiler + +

    + +
    +
    + 🎯 Master Java memory leak detection through hands-on profiling with the Spring Boot memory leak demo + +πŸ“š Course Structure + +Module 1: Foundations - 2 hours (Focus: Memory leak theory and setup; Key learning: Understanding leak patterns; profiling infrastructure) +Module 2: Profiling - 3 hours (Focus: Hands-on profiling mastery; Key learning: 21 profiling options; flamegraph interpretation) +Module 3:... +

    + [Read More] +
    +
    +
    +

    Module 4: Real-World Applications - Production Patterns and Integration

    diff --git a/docs/tags/profiling.html b/docs/tags/profiling.html new file mode 100644 index 00000000..803f00f9 --- /dev/null +++ b/docs/tags/profiling.html @@ -0,0 +1,327 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + +

    + +
    +
    +
    +
    +
    +

    #profiling

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 3: Analysis and Evidence Collection

    + +

    + +   + + java + profiling + memory-leak + analysis + evidence + documentation + +

    + +
    +
    + Systematic Analysis using @162-java-profiling-analyze +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Master the systematic analysis framework from @162-java-profiling-analyze +- Learn to categorize and prioritize performance issues using Impact/Effort scoring +- Create structured documentation following professional templates +- Develop cross-correlation analysis skills for multiple profiling results +... +

    + [Read More] +
    +
    +
    +
    +

    Module 2: Hands-on Profiling with System Prompts

    + +

    + +   + + java + profiling + memory-leak + async-profiler + flamegraph + jmeter + +

    + +
    +
    + Mastering the Interactive Profiling Script and Evidence Collection +⏱️ Duration: 3 hours +🎯 Learning Objectives: +- Master the @161-java-profiling-detect system prompt and its 21 profiling options +- Learn problem-driven profiling strategies for different performance issues +- Understand flamegraph interpretation and visual analysis techniques +- Generate comprehensive profiling evidence under realistic... +

    + [Read More] +
    +
    +
    +
    +

    Module 1: Memory Leak Foundations and Detection Setup

    + +

    + +   + + java + profiling + memory-leak + foundations + detection + setup + +

    + +
    +
    + Understanding Memory Leaks and Building Detection Infrastructure +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Understand what memory leaks are and why they're critical in Java applications +- Identify different types of memory leak patterns in enterprise applications +- Explore the Spring Boot memory leak demo architecture +- Set up automated profiling infrastructure using system prompts +- Understan... +

    + [Read More] +
    +
    +
    +
    +

    Mastering Java Memory Leak Detection - Complete Learning Path

    + +

    + +   + + java + profiling + memory-leak + performance + system-prompts + async-profiler + +

    + +
    +
    + 🎯 Master Java memory leak detection through hands-on profiling with the Spring Boot memory leak demo + +πŸ“š Course Structure + +Module 1: Foundations - 2 hours (Focus: Memory leak theory and setup; Key learning: Understanding leak patterns; profiling infrastructure) +Module 2: Profiling - 3 hours (Focus: Hands-on profiling mastery; Key learning: 21 profiling options; flamegraph interpretation) +Module 3:... +

    + [Read More] +
    +
    +
    +
    +

    Module 5: Validation and Comparison

    + +

    + +   + + java + profiling + memory-leak + validation + comparison + before-after + +

    + +
    +
    + Rigorous Before/After Analysis using @164-java-profiling-compare +⏱️ Duration: 1 hour +🎯 Learning Objectives: +- Master the @164-java-profiling-compare system prompt for rigorous validation +- Generate comprehensive before/after profiling comparisons +- Create quantitative evidence of memory leak resolution +- Document measurable performance improvements +- Establish ongoing monitoring strategies for pro... +

    + [Read More] +
    +
    +
    +
    +

    Module 4: Refactoring and Solution Implementation

    + +

    + +   + + java + profiling + memory-leak + refactoring + implementation + validation + +

    + +
    +
    + Implementing Memory Leak Fixes and Validation +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Implement the prioritized solutions identified in Module 3 +- Understand the coco=false configuration pattern for immediate leak resolution +- Understand proper resource lifecycle management patterns +- Validate that fixes are correctly applied and effective +- Set up monitoring and alerting for ongoing protect... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/real-world.html b/docs/tags/real-world.html index 9a0a4730..3e6037bf 100644 --- a/docs/tags/real-world.html +++ b/docs/tags/real-world.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/records.html b/docs/tags/records.html index 180bec2f..6434eb93 100644 --- a/docs/tags/records.html +++ b/docs/tags/records.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/refactoring.html b/docs/tags/refactoring.html new file mode 100644 index 00000000..59628b43 --- /dev/null +++ b/docs/tags/refactoring.html @@ -0,0 +1,174 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #refactoring

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 4: Refactoring and Solution Implementation

    + +

    + +   + + java + profiling + memory-leak + refactoring + implementation + validation + +

    + +
    +
    + Implementing Memory Leak Fixes and Validation +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Implement the prioritized solutions identified in Module 3 +- Understand the coco=false configuration pattern for immediate leak resolution +- Understand proper resource lifecycle management patterns +- Validate that fixes are correctly applied and effective +- Set up monitoring and alerting for ongoing protect... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/sealed-types.html b/docs/tags/sealed-types.html index 61701cb6..a187ac0c 100644 --- a/docs/tags/sealed-types.html +++ b/docs/tags/sealed-types.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/self-bounded.html b/docs/tags/self-bounded.html index 4beee25a..c29586bc 100644 --- a/docs/tags/self-bounded.html +++ b/docs/tags/self-bounded.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/serialization.html b/docs/tags/serialization.html index 867d0de9..3301ae27 100644 --- a/docs/tags/serialization.html +++ b/docs/tags/serialization.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/setup.html b/docs/tags/setup.html new file mode 100644 index 00000000..494a1dbc --- /dev/null +++ b/docs/tags/setup.html @@ -0,0 +1,174 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #setup

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Module 1: Memory Leak Foundations and Detection Setup

    + +

    + +   + + java + profiling + memory-leak + foundations + detection + setup + +

    + +
    +
    + Understanding Memory Leaks and Building Detection Infrastructure +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Understand what memory leaks are and why they're critical in Java applications +- Identify different types of memory leak patterns in enterprise applications +- Explore the Spring Boot memory leak demo architecture +- Set up automated profiling infrastructure using system prompts +- Understan... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/support.html b/docs/tags/support.html index 976afe16..6c8d7e33 100644 --- a/docs/tags/support.html +++ b/docs/tags/support.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -90,13 +91,13 @@

    Frequently As
    - ❓ Frequently Asked Questions -πŸ“š Course Content + πŸ“š Course Content Q: What Java version do I need for this course? A: The course is designed for Java 17+ (LTS), but most concepts work from Java 8+. Modern features like Records and sealed types require Java 14+ and Java 17+ respectively. Q: How long does it take to complete the course? A: The full course is designed for 12-15 hours: -- Quick Start: 2 hours (essentials o... +- Quick Start: 2 hours (essentials only) +- Comprehensive: 12-15 h...

    [Read More]
    diff --git a/docs/tags/system-prompts.html b/docs/tags/system-prompts.html new file mode 100644 index 00000000..945fa2b4 --- /dev/null +++ b/docs/tags/system-prompts.html @@ -0,0 +1,173 @@ + + + + + + + + Cursor Rules for Java + + + + + + + + + + + + + + + + + + + + +
    +
    +
    +
    +
    +

    #system-prompts

    +
    +
    +
    +
    +
    + +
    +
    +
    + +
    +
    +

    Mastering Java Memory Leak Detection - Complete Learning Path

    + +

    + +   + + java + profiling + memory-leak + performance + system-prompts + async-profiler + +

    + +
    +
    + 🎯 Master Java memory leak detection through hands-on profiling with the Spring Boot memory leak demo + +πŸ“š Course Structure + +Module 1: Foundations - 2 hours (Focus: Memory leak theory and setup; Key learning: Understanding leak patterns; profiling infrastructure) +Module 2: Profiling - 3 hours (Focus: Hands-on profiling mastery; Key learning: 21 profiling options; flamegraph interpretation) +Module 3:... +

    + [Read More] +
    +
    +
    +
    + +
    +
    +
    + + + + + + + + + + + + + + + diff --git a/docs/tags/type-erasure.html b/docs/tags/type-erasure.html index 2f732013..288f1b56 100644 --- a/docs/tags/type-erasure.html +++ b/docs/tags/type-erasure.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/type-safety.html b/docs/tags/type-safety.html index e7233e13..c47f4c9e 100644 --- a/docs/tags/type-safety.html +++ b/docs/tags/type-safety.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/validation.html b/docs/tags/validation.html index 8a8ad806..d91f5ce6 100644 --- a/docs/tags/validation.html +++ b/docs/tags/validation.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • @@ -74,6 +75,68 @@
    +

    Module 5: Validation and Comparison

    + +

    + +   + + java + profiling + memory-leak + validation + comparison + before-after + +

    + +
    +
    + Rigorous Before/After Analysis using @164-java-profiling-compare +⏱️ Duration: 1 hour +🎯 Learning Objectives: +- Master the @164-java-profiling-compare system prompt for rigorous validation +- Generate comprehensive before/after profiling comparisons +- Create quantitative evidence of memory leak resolution +- Document measurable performance improvements +- Establish ongoing monitoring strategies for pro... +

    + [Read More] +
    +
    +
    +
    +

    Module 4: Refactoring and Solution Implementation

    + +

    + +   + + java + profiling + memory-leak + refactoring + implementation + validation + +

    + +
    +
    + Implementing Memory Leak Fixes and Validation +⏱️ Duration: 2 hours +🎯 Learning Objectives: +- Implement the prioritized solutions identified in Module 3 +- Understand the coco=false configuration pattern for immediate leak resolution +- Understand proper resource lifecycle management patterns +- Validate that fixes are correctly applied and effective +- Set up monitoring and alerting for ongoing protect... +

    + [Read More] +
    +
    +
    +

    Module 5: Assessment - Validate Your Mastery

    diff --git a/docs/tags/variance.html b/docs/tags/variance.html index f35228d8..5753bd42 100644 --- a/docs/tags/variance.html +++ b/docs/tags/variance.html @@ -43,6 +43,7 @@ Courses

    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/docs/tags/wildcards.html b/docs/tags/wildcards.html index 3fdbd7fd..4ee03986 100644 --- a/docs/tags/wildcards.html +++ b/docs/tags/wildcards.html @@ -43,6 +43,7 @@ Courses
    Java Generics + Memory Leak Profiling
  • Archive
    • diff --git a/examples/spring-boot-memory-leak-demo/README-DEV.md b/examples/spring-boot-memory-leak-demo/README-DEV.md index 9025de03..4c687552 100644 --- a/examples/spring-boot-memory-leak-demo/README-DEV.md +++ b/examples/spring-boot-memory-leak-demo/README-DEV.md @@ -5,7 +5,7 @@ This demo includes two controllers that can be conditionally enabled based on the `coco` property: - **CocoController**: Contains intentional memory leaks for demonstration purposes -- **WithoutCocoController**: Proper implementation with resource management +- **NoCocoController**: Proper implementation with resource management ### Configuration Options @@ -15,14 +15,14 @@ Set the `coco` property in your application properties: # Enable CocoController (with memory leaks for demo purposes) coco=true -# Enable WithoutCocoController (proper resource management) +# Enable NoCocoController (proper resource management) coco=false ``` ### Profile-Specific Configuration - **Default profile** (`application.properties`): `coco=true` (enables CocoController) -- **Virtual Threads profile** (`application-vt.properties`): `coco=false` (enables WithoutCocoController) +- **Virtual Threads profile** (`application-vt.properties`): `coco=false` (enables NoCocoController) ### Usage Examples @@ -30,7 +30,7 @@ coco=false # Run with CocoController (memory leaks) ./mvnw spring-boot:run -# Run with WithoutCocoController (proper resource management) +# Run with NoCocoController (proper resource management) ./mvnw spring-boot:run -Dspring.profiles.active=vt # Override property at runtime diff --git a/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-comparison-analysis-20250720.md b/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-comparison-analysis-20250720.md index 19e01506..2c4dd927 100644 --- a/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-comparison-analysis-20250720.md +++ b/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-comparison-analysis-20250720.md @@ -1,7 +1,7 @@ # Profiling Comparison Analysis - July 20, 2025 ## Executive Summary -- **Refactoring Objective**: Eliminate memory leaks by swapping from CocoController to WithoutCocoController +- **Refactoring Objective**: Eliminate memory leaks by swapping from CocoController to NoCocoController - **Overall Result**: βœ… **SUCCESS** - Memory leaks completely eliminated - **Key Improvements**: 99%+ thread reduction, stable memory retention, 55% baseline memory improvement @@ -10,7 +10,7 @@ - **Post-Refactoring Date**: 2025-07-20 20:28 (after controller swap) - **Test Scenarios**: Memory allocation endpoints with sustained load - **Duration**: 300+ seconds of continuous profiling -- **Refactoring Applied**: Controller swap - deactivated CocoController, activated WithoutCocoController +- **Refactoring Applied**: Controller swap - deactivated CocoController, activated NoCocoController ## Before/After Metrics | Metric | Before (19:31) | After (20:28) | Improvement | @@ -40,7 +40,7 @@ GC(10): 361Mβ†’105M (105M retained) [+114% growth] GC(11): 395Mβ†’135M (135M retained) [+176% growth] Pattern: MEMORY LEAK - growing retention -AFTER (20:28 - WithoutCocoController active): +AFTER (20:28 - NoCocoController active): GC(7): 311Mβ†’22M (22M retained) [Baseline] GC(8): 287Mβ†’22M (22M retained) [Stable] Pattern: HEALTHY - stable retention @@ -57,7 +57,7 @@ Improvement: 99.25% reduction in thread overhead **Controller Implementation Status:** - βœ… **CocoController**: Properly deactivated (`@RestController` and `@RequestMapping` commented out) -- βœ… **WithoutCocoController**: Successfully activated with proper annotations +- βœ… **NoCocoController**: Successfully activated with proper annotations - βœ… **Bounded Collections**: `MAX_OBJECTS = 10000` limit implemented - βœ… **Thread Lifecycle**: `@PreDestroy` cleanup implemented diff --git a/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-final-results-20250720.md b/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-final-results-20250720.md index 01b9326a..dfc1c1ac 100644 --- a/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-final-results-20250720.md +++ b/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-final-results-20250720.md @@ -17,15 +17,15 @@ ## Critical Issues Resolved 1. **Memory Leak Elimination**: Successfully stopped unbounded memory growth pattern - **Evidence**: GC retention stabilized from growing (49Mβ†’77Mβ†’105Mβ†’135M) to stable (22Mβ†’22M) - - **Root Cause**: Controller swap from CocoController to WithoutCocoController + - **Root Cause**: Controller swap from CocoController to NoCocoController 2. **Thread Pool Leak Resolution**: Eliminated ExecutorService lifecycle issues - **Evidence**: Thread dump size reduced by 99.25% (5.9MB β†’ 44KB) - - **Root Cause**: Implemented proper `@PreDestroy` cleanup in WithoutCocoController + - **Root Cause**: Implemented proper `@PreDestroy` cleanup in NoCocoController 3. **Bounded Collections Implementation**: Prevented unbounded object accumulation - **Evidence**: Memory baseline improved by 55% (49MB β†’ 22MB) - - **Root Cause**: Added `MAX_OBJECTS = 10000` limit in WithoutCocoController + - **Root Cause**: Added `MAX_OBJECTS = 10000` limit in NoCocoController ## Technical Validation @@ -36,10 +36,10 @@ //@RequestMapping("/api/v1") public class CocoController { -// WithoutCocoController.java - ACTIVATED +// NoCocoController.java - ACTIVATED @RestController @RequestMapping("/api/v1") -public class WithoutCocoController { +public class NoCocoController { private static final int MAX_OBJECTS = 10000; @PreDestroy public void cleanup() { /* proper thread cleanup */ } @@ -58,7 +58,7 @@ AFTER: 44,533 bytes (proper lifecycle) ## Production Readiness βœ… - [x] **Performance targets met**: Memory leaks eliminated, 55% memory improvement -- [x] **No regressions introduced**: All functionality maintained with WithoutCocoController +- [x] **No regressions introduced**: All functionality maintained with NoCocoController - [x] **Load testing completed**: Sustained profiling confirms stability under load - [x] **Monitoring alerts configured**: GC logging active for ongoing monitoring @@ -92,7 +92,7 @@ AFTER: 44,533 bytes (proper lifecycle) ## Conclusion -The refactoring objective has been **completely achieved**. The controller swap from CocoController to WithoutCocoController successfully eliminated all identified memory leaks, with clear quantitative evidence: +The refactoring objective has been **completely achieved**. The controller swap from CocoController to NoCocoController successfully eliminated all identified memory leaks, with clear quantitative evidence: - **Memory leaks eliminated** (stable 22MB retention vs growing 49Mβ†’135M pattern) - **Thread pool leaks resolved** (99.25% reduction in thread overhead) diff --git a/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-problem-analysis-20250720.md b/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-problem-analysis-20250720.md index e4ca53d5..c22ca28c 100644 --- a/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-problem-analysis-20250720.md +++ b/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-problem-analysis-20250720.md @@ -80,7 +80,7 @@ public ResponseEntity getObjectsParty() { ### Solution Exists But Not Deployed -**CRITICAL FINDING**: A proper implementation exists in `WithoutCocoController` that addresses all memory leak issues: +**CRITICAL FINDING**: A proper implementation exists in `NoCocoController` that addresses all memory leak issues: βœ… **Proper Thread Management:** ```java @@ -117,7 +117,7 @@ if (objects.size() >= MAX_OBJECTS) { ### Priority 1: CRITICAL (Deploy Today) 1. **Deactivate CocoController**: Comment out `@RestController` annotation -2. **Activate WithoutCocoController**: Uncomment `@RestController` annotation +2. **Activate NoCocoController**: Uncomment `@RestController` annotation 3. **Immediate Testing**: Verify memory leak resolution 4. **Production Deployment**: Deploy fixed version immediately @@ -137,7 +137,7 @@ if (objects.size() >= MAX_OBJECTS) { 1. Fix was analyzed but never deployed to running system 2. Code regression after successful fix 3. Testing environment vs production environment discrepancy -4. Analysis based on `WithoutCocoController` but deployment uses `CocoController` +4. Analysis based on `NoCocoController` but deployment uses `CocoController` ## Risk Assessment diff --git a/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-solutions-20250720.md b/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-solutions-20250720.md index 262b97ed..4fb254d7 100644 --- a/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-solutions-20250720.md +++ b/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-solutions-20250720.md @@ -6,12 +6,12 @@ ### Solution 1: Immediate Controller Swap - **Problem**: Critical memory leaks in active `CocoController` causing 318% memory retention increase -- **Solution**: Switch from problematic `CocoController` to fixed `WithoutCocoController` +- **Solution**: Switch from problematic `CocoController` to fixed `NoCocoController` - **Expected Impact**: Eliminate memory leaks immediately, reduce memory retention to baseline levels - **Implementation Effort**: 5 minutes (configuration change) - **Code Changes**: - `CocoController.java`: Comment out `@RestController` and `@RequestMapping` annotations - - `WithoutCocoController.java`: Uncomment `@RestController` and `@RequestMapping` annotations + - `NoCocoController.java`: Uncomment `@RestController` and `@RequestMapping` annotations **Immediate Implementation Steps:** ```java @@ -20,10 +20,10 @@ //@RequestMapping("/api/v1") public class CocoController { -// In WithoutCocoController.java - ACTIVATE +// In NoCocoController.java - ACTIVATE @RestController @RequestMapping("/api/v1") -public class WithoutCocoController { +public class NoCocoController { ``` ### Solution 2: Emergency Memory Monitoring @@ -40,7 +40,7 @@ public class WithoutCocoController { - **Solution**: Implement proper thread pool lifecycle with shared resources - **Expected Impact**: Eliminate thread pool leaks, reduce thread overhead by 90% - **Implementation Effort**: 2 hours (class refactoring) -- **Code Changes**: Already implemented in `WithoutCocoController` +- **Code Changes**: Already implemented in `NoCocoController` **Technical Implementation:** ```java @@ -62,7 +62,7 @@ public void cleanup() throws InterruptedException { - **Solution**: Implement collection size limits with proper error handling - **Expected Impact**: Cap memory usage growth, provide graceful degradation - **Implementation Effort**: 1 hour (bounds checking) -- **Code Changes**: Already implemented in `WithoutCocoController` +- **Code Changes**: Already implemented in `NoCocoController` **Technical Implementation:** ```java @@ -102,7 +102,7 @@ if (objects.size() >= MAX_OBJECTS) { ## Implementation Plan ### Phase 1: Emergency Response (Next 2 Hours) -1. **Hour 1**: Switch to `WithoutCocoController` immediately +1. **Hour 1**: Switch to `NoCocoController` immediately 2. **Hour 2**: Validate memory leak resolution with quick profiling run 3. **Verification**: Confirm GC retention stabilizes at baseline levels diff --git a/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-summary-20250720.md b/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-summary-20250720.md index 2a083229..9c3144a8 100644 --- a/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-summary-20250720.md +++ b/examples/spring-boot-memory-leak-demo/profiler/docs/profiling-summary-20250720.md @@ -18,7 +18,7 @@ Despite June 28, 2025 analysis concluding successful remediation with "26.2% imp ## Root Cause Analysis ### The Fix Exists But Isn't Deployed -- βœ… **Solution Available**: `WithoutCocoController` properly addresses all memory leaks +- βœ… **Solution Available**: `NoCocoController` properly addresses all memory leaks - ❌ **Problem**: `CocoController` (with leaks) is still the active implementation - ❌ **Gap**: Deployment process didn't implement the analyzed fixes @@ -65,7 +65,7 @@ GC(14): 445Mβ†’205M (205M retained) [+318% growth] ## Solution Validation ### The Fix Works βœ… -`WithoutCocoController` implements proper resource management: +`NoCocoController` implements proper resource management: - **Thread Pool**: Shared ExecutorService with proper lifecycle management - **Memory Bounds**: Collection size limits (MAX_OBJECTS = 10,000) - **Resource Cleanup**: @PreDestroy methods ensure proper shutdown @@ -110,7 +110,7 @@ Memory Alert Thresholds: **The application has active memory leaks that will cause production failures.** ### Next 2 Hours: Emergency Response -1. **Deploy Fix**: Switch to `WithoutCocoController` immediately +1. **Deploy Fix**: Switch to `NoCocoController` immediately 2. **Validate**: Run quick profiling to confirm leak resolution 3. **Monitor**: Watch GC retention patterns stabilize diff --git a/site-generator/content/blog/2025/prompt-quality-framework.md b/site-generator/content/blog/2025/prompt-quality-framework.md index c26d79e9..01ad8940 100644 --- a/site-generator/content/blog/2025/prompt-quality-framework.md +++ b/site-generator/content/blog/2025/prompt-quality-framework.md @@ -2,6 +2,7 @@ title=The Three-Node Quality Framework for AI Prompts date=2025-07-20 type=post tags=blog +author=Juan Antonio BreΓ±a Moral status=published ~~~~~~ diff --git a/site-generator/content/blog/2025/release-0.10.0.md b/site-generator/content/blog/2025/release-0.10.0.md index d86379c6..4cbcbfb8 100644 --- a/site-generator/content/blog/2025/release-0.10.0.md +++ b/site-generator/content/blog/2025/release-0.10.0.md @@ -2,6 +2,7 @@ title=What's new in Cursor rules for Java 0.10.0? date=2025-09-05 type=post tags=blog +author=Juan Antonio BreΓ±a Moral status=published ~~~~~~ diff --git a/site-generator/content/blog/2025/release-0.8.0.md b/site-generator/content/blog/2025/release-0.8.0.md index 2509e7a5..481eef16 100644 --- a/site-generator/content/blog/2025/release-0.8.0.md +++ b/site-generator/content/blog/2025/release-0.8.0.md @@ -2,6 +2,7 @@ title=What's new in Cursor rules for Java 0.8.0? date=2025-07-12 type=post tags=blog +author=Juan Antonio BreΓ±a Moral status=published ~~~~~~ diff --git a/site-generator/content/blog/2025/release-0.9.0.md b/site-generator/content/blog/2025/release-0.9.0.md index 99223aa2..d5313db1 100644 --- a/site-generator/content/blog/2025/release-0.9.0.md +++ b/site-generator/content/blog/2025/release-0.9.0.md @@ -2,6 +2,7 @@ title=What's new in Cursor rules for Java 0.9.0? date=2025-07-23 type=post tags=blog +author=Juan Antonio BreΓ±a Moral status=published ~~~~~~ diff --git a/site-generator/content/courses/java-generics/faq.md b/site-generator/content/courses/java-generics/faq.md index 97aa995d..d68673cd 100644 --- a/site-generator/content/courses/java-generics/faq.md +++ b/site-generator/content/courses/java-generics/faq.md @@ -6,8 +6,6 @@ author=Juan Antonio BreΓ±a Moral tags=java, generics, faq, help, support ~~~~~~ -# ❓ Frequently Asked Questions - ## πŸ“š Course Content ### Q: What Java version do I need for this course? diff --git a/site-generator/content/courses/profile-memory-leak/index.md b/site-generator/content/courses/profile-memory-leak/index.md new file mode 100644 index 00000000..3e0ee73b --- /dev/null +++ b/site-generator/content/courses/profile-memory-leak/index.md @@ -0,0 +1,261 @@ +title=Mastering Java Memory Leak Detection - Complete Learning Path +type=course +status=published +date=2025-09-17 +author=Juan Antonio BreΓ±a Moral +version=0.11.0-SNAPSHOT +tags=java, profiling, memory-leak, performance, system-prompts, async-profiler +~~~~~~ + +🎯 **Master Java memory leak detection through hands-on profiling with the Spring Boot memory leak demo** + +--- + +## πŸ“š Course Structure + +- [Module 1: Foundations](module-1-foundations.html) - 2 hours (Focus: Memory leak theory and setup; Key learning: Understanding leak patterns; profiling infrastructure) +- [Module 2: Profiling](module-2-profiling.html) - 3 hours (Focus: Hands-on profiling mastery; Key learning: 21 profiling options; flamegraph interpretation) +- [Module 3: Analysis](module-3-analysis.html) - 2 hours (Focus: Systematic analysis; Key learning: Evidence documentation; prioritization frameworks) +- [Module 4: Refactoring](module-4-refactoring.html) - 2 hours (Focus: Solution implementation; Key learning: Resource lifecycle patterns; coco=false fix) +- [Module 5: Validation](module-5-validation.html) - 1 hour (Focus: Before/after comparison; Key learning: Quantitative validation; success measurement) + +**Total Duration:** 8-12 hours (depending on learning path) +### **Module 1: Memory Leak Foundations and Detection Setup** (2 hours) +**Learning Focus:** Understanding memory leaks and setting up detection infrastructure + +**Key Topics:** +- What are memory leaks and why they matter? +- Types of memory leaks in Java applications +- Introduction to the Spring Boot memory leak demo +- Setting up profiling infrastructure with system prompts +- Understanding the `coco=true/false` configuration pattern + +**Hands-on Activities:** +- Explore the CocoController vs NoCocoController implementations +- Set up profiling scripts using @161-java-profiling-detect +- Run initial baseline profiling session + +**Learning Outcomes:** +- Identify different types of memory leak patterns +- Set up automated profiling environment +- Understand the demo application architecture + +--- + +### **Module 2: Hands-on Profiling with System Prompts** (3 hours) +**Learning Focus:** Using system prompts to systematically collect profiling data + +**Key Topics:** +- Deep dive into @161-java-profiling-detect system prompt +- Interactive profiling script walkthrough (21 profiling options) +- Memory leak detection strategies (5-minute vs 30-second profiles) +- JMeter load testing integration for realistic scenarios +- Understanding flamegraph interpretation + +**Hands-on Activities:** +- Execute memory allocation profiling (Option 2) +- Run memory leak detection workflow (Option 8) +- Generate JMeter load tests for consistent profiling conditions +- Create comprehensive memory analysis workflow (Option 9) + +**Learning Outcomes:** +- Master the interactive profiling script +- Generate meaningful profiling data under load +- Interpret flamegraph visualizations effectively + +--- + +### **Module 3: Analysis and Evidence Collection** (2 hours) +**Learning Focus:** Systematic analysis using @162-java-profiling-analyze + +**Key Topics:** +- Systematic analysis framework for profiling data +- Problem categorization and severity assessment +- Evidence documentation with quantitative metrics +- Cross-correlation analysis techniques +- Impact vs Effort prioritization framework + +**Hands-on Activities:** +- Analyze flamegraphs to identify memory leak patterns +- Create problem analysis documents following templates +- Develop prioritized solution recommendations +- Document evidence with specific file references + +**Learning Outcomes:** +- Systematically analyze profiling results +- Create structured documentation for findings +- Prioritize fixes using Impact/Effort scoring + +--- + +### **Module 4: Refactoring and Solution Implementation** (2 hours) +**Learning Focus:** Implementing fixes based on analysis findings + +**Key Topics:** +- Understanding the `coco=false` refactoring strategy +- Thread pool lifecycle management +- Bounded collections implementation +- Resource cleanup patterns (@PreDestroy) +- Deployment verification procedures + +**Hands-on Activities:** +- Switch from CocoController to NoCocoController +- Verify code changes are properly applied +- Implement monitoring and alerting +- Test application stability after refactoring + +**Learning Outcomes:** +- Apply systematic refactoring strategies +- Implement proper resource management patterns +- Validate refactoring through testing + +--- + +### **Module 5: Validation and Comparison** (1 hour) +**Learning Focus:** Using @164-java-profiling-compare to validate improvements + +**Key Topics:** +- Before/after comparison methodology +- Quantitative metrics extraction +- Visual flamegraph comparison techniques +- Success criteria validation +- Documentation of improvements + +**Hands-on Activities:** +- Generate post-refactoring profiling reports +- Perform side-by-side flamegraph comparison +- Create comparison analysis documentation +- Validate performance improvement targets + +**Learning Outcomes:** +- Rigorously validate performance improvements +- Document quantified results +- Establish ongoing monitoring strategies + +--- + +## πŸ› οΈ Tools and Technologies + +### **Primary Tools:** +- **async-profiler v4.1**: Advanced profiling with flamegraph generation +- **JFR (Java Flight Recorder)**: Low-overhead continuous profiling +- **JMeter**: Load testing for realistic profiling scenarios +- **Spring Boot Actuator**: Application monitoring and health checks + +### **System Prompts Used:** +- **@161-java-profiling-detect**: Setup and data collection +- **@162-java-profiling-analyze**: Systematic analysis framework +- **@164-java-profiling-compare**: Before/after validation +- **@151-java-performance-jmeter**: Load testing integration + +### **Visualization Techniques:** +- **Flamegraphs**: Call stack and allocation visualization +- **Heatmaps**: Temporal analysis of performance hotspots +- **Memory usage charts**: GC retention and heap growth patterns +- **Thread dumps**: Concurrency and threading analysis + +--- + +## πŸ› οΈ System Prompts Integration + +This course demonstrates practical usage of three key system prompts: + +### **[@161-java-profiling-detect](https://github.com/jabrena/cursor-rules-java/tree/main/.cursor/rules/161-java-profiling-detect.md)** +**Purpose:** Data collection and problem identification +**Usage:** My Java application has performance issues - help me set up comprehensive profiling process using @161-java-profiling-detect and use the location examples/spring-boot-memory-leak-demo/profiler + +### **[@162-java-profiling-analyze](https://github.com/jabrena/cursor-rules-java/tree/main/.cursor/rules/162-java-profiling-analyze.md)** +**Purpose:** Systematic analysis and solution development +**Usage:** Analyze the results located in examples/spring-boot-memory-leak-demo/profiler and use the cursor rule @162-java-profiling-analyze + +### **[@164-java-profiling-compare](https://github.com/jabrena/cursor-rules-java/tree/main/.cursor/rules/164-java-profiling-compare.md)** +**Purpose:** Before/after validation and improvement measurement +**Usage:** Review if the problems was solved with last refactoring using the reports located in @/results with the cursor rule @164-java-profiling-compare + +--- + +## 🎯 Key Concepts Covered + +### **Memory Leak Patterns** +- βœ… Unbounded collection growth +- βœ… Thread pool resource leaks +- βœ… Missing lifecycle management +- βœ… Cache leaks and retention issues + +### **Profiling Techniques** +- βœ… async-profiler mastery (21 profiling options) +- βœ… JFR analysis and interpretation +- βœ… Flamegraph visual analysis +- βœ… Load testing integration with JMeter + +### **Enterprise Patterns** +- βœ… Bounded collections with graceful degradation +- βœ… Shared resource management +- βœ… `@PreDestroy` lifecycle patterns +- βœ… Monitoring and alerting infrastructure + +### **Analysis Methodologies** +- βœ… Problem-driven profiling strategies +- βœ… Impact/Effort prioritization frameworks +- βœ… Cross-correlation analysis techniques +- βœ… Evidence-based documentation + +--- + +## πŸ” Interactive Elements Throughout the Course + +### **🧠 Knowledge Checks** +- "Before we continue, can you explain why GC retention grows with active memory leaks?" +- "What would happen if we didn't implement @PreDestroy in our thread pools?" +- "How do you interpret a flamegraph where the canvas height keeps growing?" + +### **πŸ’‘ Learning Reinforcement** +- "Notice how the NoCocoController eliminates the memory leak - that's the power of proper resource lifecycle management!" +- "This connects to our earlier lesson on bounded collections - remember the MAX_OBJECTS pattern?" +- "The 318% memory retention increase we observed demonstrates why systematic profiling is critical!" + +### **🎯 Practical Challenges** +- Implement custom bounded collections with error handling +- Design monitoring strategies for production memory leak detection +- Create custom profiling configurations for specific scenarios +- Develop team knowledge transfer materials + +--- + +## πŸ“Š Success Metrics and Validation + +### **Technical Success Criteria** +- [ ] Memory leaks successfully detected and resolved +- [ ] Quantified performance improvements documented +- [ ] Systematic profiling workflow mastered +- [ ] Production-ready monitoring strategy developed + +### **Learning Validation Methods** +- [ ] Hands-on exercises completed successfully +- [ ] Profiling reports generated and analyzed +- [ ] Documentation created following professional templates +- [ ] Knowledge check questions answered correctly + +### **Real-World Application** +- [ ] Techniques applied to actual production applications +- [ ] Team knowledge sharing sessions conducted +- [ ] Performance monitoring integrated into CI/CD pipeline +- [ ] Continuous improvement processes established + +--- + +## πŸŽ“ Course Philosophy + +### **Progressive Learning Design** +This course follows the **@behaviour-progressive-learning** pattern: +- **Extract** core concepts from system prompts +- **Structure** content into progressive learning modules +- **Create** interactive exercises with guided solutions +- **Generate** comprehensive courses with multiple paths +- **Provide** assessments and validation checkpoints + +--- + +*"The best time to learn performance optimization was yesterday. The second best time is now."* + +**Happy profiling! [Go to the foundations](module-1-foundations.html) πŸš€** diff --git a/site-generator/content/courses/profile-memory-leak/module-1-foundations.md b/site-generator/content/courses/profile-memory-leak/module-1-foundations.md new file mode 100644 index 00000000..63886cdd --- /dev/null +++ b/site-generator/content/courses/profile-memory-leak/module-1-foundations.md @@ -0,0 +1,402 @@ +title=Module 1: Memory Leak Foundations and Detection Setup +type=course +status=published +date=2025-09-17 +author=Juan Antonio BreΓ±a Moral +version=0.11.0-SNAPSHOT +tags=java, profiling, memory-leak, foundations, detection, setup +~~~~~~ + +## Understanding Memory Leaks and Building Detection Infrastructure + +**⏱️ Duration:** 2 hours +**🎯 Learning Objectives:** +- Understand what memory leaks are and why they're critical in Java applications +- Identify different types of memory leak patterns in enterprise applications +- Explore the Spring Boot memory leak demo architecture +- Set up automated profiling infrastructure using system prompts +- Understand the `coco=true/false` configuration pattern for controlled testing + +--- + +## 🧠 Conceptual Foundation + +### What Are Memory Leaks in Java? + +**Definition:** A memory leak in Java occurs when objects that are no longer needed by the application remain referenced and cannot be garbage collected, leading to gradual memory exhaustion. + +**πŸ” Key Insight:** Unlike languages with manual memory management (C/C++), Java memory leaks are typically caused by **logical errors** where references to unused objects are unintentionally retained. + +### Types of Memory Leaks in Java Applications + +#### 1. **Collection Leaks** +```java +// BAD: Unbounded growth +private final List requests = new ArrayList<>(); + +public void processRequest(RequestData data) { + requests.add(data); // Never removed! +} +``` + +#### 2. **Thread Pool Leaks** +```java +// BAD: ExecutorService never shutdown +public void createTask() { + ExecutorService executor = Executors.newFixedThreadPool(10); + executor.submit(() -> doWork()); + // Missing: executor.shutdown()! +} +``` + +#### 3. **Listener/Callback Leaks** +```java +// BAD: Listeners never removed +public void addListener(EventListener listener) { + eventListeners.add(listener); // Accumulates forever +} +``` + +#### 4. **Cache Leaks** +```java +// BAD: No eviction policy +private final Map cache = new HashMap<>(); + +public ExpensiveObject get(String key) { + return cache.computeIfAbsent(key, k -> new ExpensiveObject(k)); + // Cache grows indefinitely! +} +``` + +### πŸ’‘ Learning Reinforcement +**Notice how each leak type involves the same pattern: objects being added to collections or caches without corresponding removal logic. This is why systematic profiling is essential - these patterns are often subtle and hard to spot in code reviews!** + +--- + +## πŸ—οΈ Demo Application Architecture + +### Understanding the Spring Boot Memory Leak Demo + +The `spring-boot-memory-leak-demo` project demonstrates controlled memory leak scenarios through two contrasting controller implementations: + +#### **CocoController (coco=true) - The Problematic Implementation** + +```java +@RestController +@RequestMapping("/api/v1") +@ConditionalOnProperty(name = "coco", havingValue = "true", matchIfMissing = true) +public class CocoController { + + // LEAK 1: Unbounded list growth + private final List objects = new ArrayList<>(); + + // LEAK 2: Thread pools created without cleanup + @PostMapping("/threads/create") + public ResponseEntity createThread() { + ExecutorService executor = Executors.newFixedThreadPool(5); + // Missing shutdown logic! + return ResponseEntity.ok("Thread created"); + } + + // LEAK 3: Unbounded object accumulation + @PostMapping("/objects/create") + public ResponseEntity createObject() { + objects.add(new MyPojo(/* large data */)); + return ResponseEntity.ok("Object created: " + objects.size()); + } +} +``` + +#### **NoCocoController (coco=false) - The Fixed Implementation** + +```java +@RestController +@RequestMapping("/api/v1") +@ConditionalOnProperty(name = "coco", havingValue = "false") +public class NoCocoController { + + private static final int MAX_OBJECTS = 10000; // Bounded! + private final List objects = Collections.synchronizedList(new ArrayList<>()); + + // Shared, managed thread pool + private final ExecutorService sharedExecutorService = + Executors.newFixedThreadPool(10, new CustomizableThreadFactory("shared-pool-")); + + @PostMapping("/objects/create") + public ResponseEntity createObject() { + // Bounds checking prevents unbounded growth + if (objects.size() >= MAX_OBJECTS) { + return ResponseEntity.badRequest() + .body("Maximum objects limit reached: " + MAX_OBJECTS); + } + objects.add(new MyPojo(/* same data */)); + return ResponseEntity.ok("Object created: " + objects.size()); + } + + // Proper resource cleanup + @PreDestroy + public void cleanup() throws InterruptedException { + sharedExecutorService.shutdown(); + if (!sharedExecutorService.awaitTermination(30, TimeUnit.SECONDS)) { + sharedExecutorService.shutdownNow(); + } + } +} +``` + +### πŸ” Knowledge Check +**Before we continue, can you identify the three main differences between these implementations that prevent memory leaks?** + +
    +Click to reveal answers + +1. **Bounded Collections**: `MAX_OBJECTS` constant prevents unbounded list growth +2. **Shared Thread Pools**: Single managed `ExecutorService` instead of creating new ones +3. **Resource Cleanup**: `@PreDestroy` method ensures proper shutdown of thread pools + +
    + +--- + +## πŸ› οΈ Setting Up Profiling Infrastructure + +### Step 1: Understanding the Configuration Pattern + +The demo uses Spring Boot's `@ConditionalOnProperty` to switch between implementations: + +```properties +# application.properties (default - enables memory leaks) +coco=true + +# application-vt.properties (virtual threads profile - fixes leaks) +coco=false +``` + +**πŸ’‘ Learning Insight:** This pattern allows us to test the exact same endpoints with different implementations, providing perfect before/after comparison scenarios for profiling! + +### Step 2: Setting Up Detection Scripts using @161-java-profiling-detect + +Let's set up the profiling infrastructure using the system prompt: + +#### **🎯 Practical Exercise 1: Initial Setup** + +1. **Navigate to the demo project:** +```bash +cd ./cursor-rules-java/examples/spring-boot-memory-leak-demo +``` + +2. **Verify the project structure:** +```bash +ls -la +# You should see: run-java-process-for-profiling.sh, profiler/ directory +``` + +3. **Check existing profiling setup:** +```bash +ls -la profiler/ +# Expected: scripts/, results/, docs/ directories +``` + +#### **🎯 Practical Exercise 2: Baseline Application Startup** + +1. **Start the application with memory leaks enabled (default):** +```bash +./run-java-process-for-profiling.sh --help +``` + +2. **Verify the application is running:** +```bash +# In another terminal +curl http://localhost:8080/actuator/health +curl http://localhost:8080/swagger-ui/index.html +``` + +3. **Check which controller is active:** +```bash +curl -X POST http://localhost:8080/api/v1/objects/create +# Should respond with "Object created: 1" +``` + +#### **🎯 Practical Exercise 3: Initial Profiling Run** + +1. **Execute the profiling script:** +```bash +cd profiler/scripts +./profile-java-process.sh --help +``` + +2. **Follow the interactive prompts:** + - **Problem Category**: Select "2) Memory-Related Problems" + - **Process Selection**: Choose your Spring Boot application + - **Profiling Option**: Select "8. Memory Leak Detection (5min)" + +3. **Generate load while profiling:** +```bash +# In another terminal, create load +for i in {1..50}; do + curl -X POST http://localhost:8080/api/v1/objects/create + curl -X POST http://localhost:8080/api/v1/threads/create + sleep 2 +done +``` + +4. **Wait for profiling to complete and examine results:** +```bash +ls -la profiler/results/ +# Look for: memory-leak-*.html files +``` + +### πŸ” Understanding Your First Profiling Results + +**Open the generated flamegraph in your browser:** +```bash +# macOS +open profiler/results/memory-leak-*.html + +# Linux +xdg-open profiler/results/memory-leak-*.html +``` + +**What to look for in the flamegraph:** +- **Canvas Height**: Tall canvas indicates many allocation paths +- **Wide Sections**: Methods consuming significant memory +- **Stack Depth**: Deep call stacks may indicate inefficient patterns +- **Color Patterns**: Different colors represent different allocation types + +### πŸ’‘ Learning Reinforcement +**This flamegraph represents the "before" state with active memory leaks. Notice the patterns - we'll compare this exact visualization after implementing fixes in later modules!** + +--- + +## πŸ“Š Baseline Metrics Collection + +### Establishing Performance Baselines + +Before we can measure improvements, we need to establish baseline metrics: + +#### **🎯 Practical Exercise 4: Comprehensive Baseline Collection** + +1. **Generate comprehensive baseline data:** +```bash +cd profiler/scripts +./profile-java-process.sh +``` + +2. **Select Option 9: Complete Memory Analysis Workflow** + - This will generate three reports: + - 30-second baseline + - 60-second detailed analysis + - 5-minute leak detection + +3. **Create sustained load for realistic metrics:** +```bash +# Run this in background while profiling +./run-jmeter.sh --help +./run-jmeter.sh -t 300 -c 5 # 5 minutes, 5 concurrent users +``` + +4. **Document your baseline results:** +```bash +ls -la profiler/results/ | grep $(date +%Y%m%d) +# Record the file names and sizes for later comparison +``` + +### Understanding JMeter Integration + +The demo includes JMeter integration for consistent load testing: + +```bash +# View the JMeter test plan +cat src/test/resources/jmeter/load-test.jmx +``` + +**Key JMeter Test Scenarios:** +- **Object Creation Load**: Repeatedly calls `/api/v1/objects/create` +- **Thread Creation Load**: Repeatedly calls `/api/v1/threads/create` +- **Mixed Workload**: Combines both endpoints with realistic timing + +### πŸ” Knowledge Check +**Why is consistent load testing crucial for memory leak detection?** + +
    +Click to reveal answer + +Memory leaks are often only visible under sustained load because: +1. **Accumulation Effect**: Leaks compound over time +2. **GC Masking**: Small leaks may be hidden by normal GC cycles +3. **Real-world Simulation**: Production applications experience continuous load +4. **Comparative Analysis**: Consistent load enables accurate before/after comparisons + +
    + +--- + +## 🎯 Module 1 Assessment + +### Hands-on Validation Checklist + +**βœ… Conceptual Understanding:** +- [ ] Can explain what causes memory leaks in Java applications +- [ ] Identified the three main leak patterns in CocoController +- [ ] Understands the coco=true/false configuration pattern + +**βœ… Technical Setup:** +- [ ] Successfully started the Spring Boot application +- [ ] Generated initial profiling reports +- [ ] Created baseline flamegraph visualizations +- [ ] Executed JMeter load testing + +**βœ… Analysis Skills:** +- [ ] Can interpret basic flamegraph patterns +- [ ] Documented baseline metrics for later comparison +- [ ] Understands the relationship between load testing and profiling + +### 🎯 Practical Challenge + +**Challenge: Custom Load Pattern** +Create a custom load testing script that exercises both problematic endpoints in a pattern that maximizes memory leak detection: + +```bash +# Create your custom load script +cat > custom-load-test.sh << 'EOF' +#!/bin/bash +echo "Starting custom memory leak load test..." + +# Your implementation here: +# 1. Create objects in bursts +# 2. Create threads periodically +# 3. Monitor memory growth +# 4. Report progress + +EOF +chmod +x custom-load-test.sh +``` + +**Success Criteria:** +- Script runs for at least 5 minutes +- Generates measurable memory growth +- Provides progress feedback +- Creates reproducible load patterns + +--- + +## πŸš€ Transition to Module 2 + +**Congratulations!** You've successfully: +- βœ… Understood the theoretical foundation of Java memory leaks +- βœ… Explored the demo application architecture +- βœ… Set up automated profiling infrastructure +- βœ… Generated baseline profiling data +- βœ… Established consistent load testing patterns + +### **What's Next?** +In **Module 2: Hands-on Profiling with System Prompts**, we'll dive deep into: +- Master all 21 profiling options in the interactive script +- Learn advanced flamegraph interpretation techniques +- Understand different profiling strategies for different problem types +- Generate comprehensive evidence for systematic analysis + +### πŸ’‘ Key Takeaway +**"The foundation of effective performance optimization is systematic measurement. You've now built the infrastructure to measure, analyze, and validate performance improvements scientifically!"** + +**Ready to dive deeper into profiling techniques? [Let's continue to Module 2!](module-2-profiling.html) 🎯** diff --git a/site-generator/content/courses/profile-memory-leak/module-2-profiling.md b/site-generator/content/courses/profile-memory-leak/module-2-profiling.md new file mode 100644 index 00000000..4461cef3 --- /dev/null +++ b/site-generator/content/courses/profile-memory-leak/module-2-profiling.md @@ -0,0 +1,573 @@ +title=Module 2: Hands-on Profiling with System Prompts +type=course +status=published +date=2025-09-17 +author=Juan Antonio BreΓ±a Moral +version=0.11.0-SNAPSHOT +tags=java, profiling, memory-leak, async-profiler, flamegraph, jmeter +~~~~~~ + +## Mastering the Interactive Profiling Script and Evidence Collection + +**⏱️ Duration:** 3 hours +**🎯 Learning Objectives:** +- Master the @161-java-profiling-detect system prompt and its 21 profiling options +- Learn problem-driven profiling strategies for different performance issues +- Understand flamegraph interpretation and visual analysis techniques +- Generate comprehensive profiling evidence under realistic load conditions +- Integrate JMeter load testing for consistent profiling scenarios + +--- + +## 🎯 Deep Dive: The Interactive Profiling Script + +### Understanding the Problem-Driven Approach + +The profiling script in @161-java-profiling-detect follows a **problem-first methodology**: + +1. **Problem Identification** β†’ 2. **Tool Selection** β†’ 3. **Data Collection** β†’ 4. **Evidence Generation** + +This approach ensures you collect the **right data** for the **specific problem** you're investigating. + +#### **πŸ” The 5 Problem Categories** + +```bash +./profiler/scripts/profile-java-process.sh +# Step 0: Problem Identification +``` + + - Performance Bottlenecks (Focus: CPU hotspots, inefficient algorithms; Recommended tools: CPU profiling, Wall-clock; Memory leak relevance: Medium - may indicate leak symptoms) + - Memory-Related Problems (Focus: Memory leaks, heap usage, retention; Recommended tools: Memory allocation, Leak detection; Memory leak relevance: **HIGH - Primary focus**) + - Concurrency/Threading (Focus: Lock contention, thread pools; Recommended tools: Lock profiling, Thread dumps; Memory leak relevance: High - thread pool leaks) + - Garbage Collection (Focus: GC pressure, long pauses; Recommended tools: GC logs, Allocation profiling; Memory leak relevance: High - GC symptoms of leaks) + - I/O and Network (Focus: Blocking operations, connection leaks; Recommended tools: Wall-clock, I/O analysis; Memory leak relevance: Medium - connection pool leaks) + +### πŸ’‘ Learning Insight +**For memory leak detection, we primarily focus on Category 2 (Memory-Related Problems), but Categories 3 and 4 provide crucial supporting evidence!** + +--- + +## πŸ› οΈ The 21 Profiling Options Masterclass + +### **Category A: Essential Memory Leak Detection Tools** + +#### **🎯 Option 2: Memory Allocation Profiling (30s)** +**When to use:** Initial memory pattern analysis +**What it shows:** Which methods allocate the most objects + +```bash +./profile-java-process.sh +# Select: 2. Memory Allocation Profiling (30s) +``` + +**🎯 Practical Exercise 1: Basic Allocation Analysis** + +1. **Start profiling with active memory leaks:** +```bash +# Ensure coco=true (memory leaks enabled) +curl http://localhost:8080/actuator/env/coco +``` + +2. **Generate consistent load during profiling:** +```bash +# In separate terminal - run this DURING profiling +for i in {1..100}; do + curl -X POST http://localhost:8080/api/v1/objects/create + sleep 0.5 +done +``` + +3. **Analyze the resulting flamegraph:** +- **Look for:** Wide sections in `CocoController.createObject` +- **Measure:** Canvas height and stack complexity +- **Document:** Specific allocation patterns + +**Expected Results:** +``` +File: allocation-flamegraph-YYYYMMDD-HHMMSS.html +Key Indicators: +- CocoController.createObject shows significant width +- MyPojo allocation patterns clearly visible +- ArrayList.add operations consume memory +``` + +#### **🎯 Option 8: Memory Leak Detection (5min)** +**When to use:** Comprehensive leak pattern analysis +**What it shows:** Long-term memory accumulation patterns + +```bash +./profile-java-process.sh +# Select: 8. Memory Leak Detection (5min) +``` + +**🎯 Practical Exercise 2: Long-term Leak Detection** + +1. **Start the 5-minute leak detection:** +```bash +# This is a long-running profiling session +./profile-java-process.sh +# Select option 8 +``` + +2. **Create sustained, realistic load:** +```bash +# Use JMeter for consistent 5-minute load +./run-jmeter.sh -t 300 -c 3 # 5 minutes, 3 concurrent users +``` + +3. **Monitor progress and system behavior:** +```bash +# In another terminal, monitor memory usage +watch -n 10 'curl -s http://localhost:8080/actuator/metrics/jvm.memory.used' +``` + +**Expected Results:** +``` +File: memory-leak-YYYYMMDD-HHMMSS.html +Key Indicators: +- Continuous memory growth patterns +- GC retention increasing over time +- Object accumulation in specific methods +``` + +#### **🎯 Option 9: Complete Memory Analysis Workflow** +**When to use:** Comprehensive memory investigation +**What it shows:** Multi-phase analysis with baseline, detailed, and leak detection + +```bash +./profile-java-process.sh +# Select: 9. Complete Memory Analysis Workflow +``` + +This option generates **three sequential reports:** +1. **30s Baseline**: Quick memory allocation snapshot +2. **60s Detailed**: In-depth heap analysis +3. **5min Leak Detection**: Long-term accumulation patterns + +**🎯 Practical Exercise 3: Complete Workflow Analysis** + +1. **Execute the complete workflow:** +```bash +# This will take about 6.5 minutes total +./profile-java-process.sh +# Select option 9 +``` + +2. **Coordinate load testing across all phases:** +```bash +# Create a script that matches the profiling phases +cat > coordinated-load.sh << 'EOF' +#!/bin/bash +echo "Phase 1: Baseline load (30s)" +timeout 30s bash -c 'while true; do curl -X POST http://localhost:8080/api/v1/objects/create; sleep 1; done' & + +echo "Phase 2: Detailed analysis load (60s)" +sleep 30 +timeout 60s bash -c 'while true; do curl -X POST http://localhost:8080/api/v1/objects/create; curl -X POST http://localhost:8080/api/v1/threads/create; sleep 0.5; done' & + +echo "Phase 3: Leak detection load (5min)" +sleep 90 +timeout 300s bash -c 'while true; do curl -X POST http://localhost:8080/api/v1/objects/create; sleep 0.3; done' & + +wait +echo "All load phases completed" +EOF +chmod +x coordinated-load.sh +``` + +3. **Execute coordinated load:** +```bash +./coordinated-load.sh +``` + +**Expected Results:** +``` +Files generated: +- memory-baseline-YYYYMMDD-HHMMSS.html (30s snapshot) +- heap-analysis-YYYYMMDD-HHMMSS.html (60s detailed) +- memory-leak-complete-YYYYMMDD-HHMMSS.html (5min comprehensive) +``` + +### **Category B: Advanced Profiling Techniques** + +#### **🎯 Option 12: All Events Profiling (30s)** +**When to use:** Comprehensive system analysis +**What it shows:** CPU, allocation, lock, and wall-clock data simultaneously + +```bash +./profile-java-process.sh +# Select: 12. All Events Profiling (30s) +``` + +**Expected Results:** +``` +Files generated: +- all-events-YYYYMMDD-HHMMSS.jfr (JFR recording) +- all-events-YYYYMMDD-HHMMSS.html (Converted flamegraph) +``` + +#### **🎯 Option 18: JFR Memory Leak Analysis with TLAB tracking** +**When to use:** Advanced memory leak investigation +**What it shows:** Thread Local Allocation Buffer patterns and object lifecycle + +**TLAB (Thread Local Allocation Buffer) Explained:** + +TLAB is a JVM optimization technique that provides each thread with its own private allocation buffer in the heap's Eden space. This eliminates contention when multiple threads allocate objects simultaneously. + +**Key TLAB Concepts:** +- **Private Buffer**: Each thread gets its own allocation space (typically 1-256KB) +- **Fast Allocation**: Objects are allocated via simple pointer bumping (no synchronization) +- **Automatic Management**: JVM automatically manages TLAB size based on allocation patterns +- **Waste Tracking**: Unused TLAB space is tracked as "waste" for performance tuning + +**TLAB and Memory Leaks:** +- **Allocation Patterns**: TLAB tracking reveals which threads allocate the most objects +- **Leak Detection**: Threads with consistently growing TLAB usage may indicate leaks +- **Performance Impact**: Memory leaks can cause frequent TLAB allocation/deallocation +- **GC Pressure**: Excessive TLAB waste increases garbage collection frequency + +**Profiling with TLAB:** +- **JFR Events**: `jdk.ObjectAllocationInNewTLAB` and `jdk.ObjectAllocationOutsideTLAB` +- **Allocation Tracking**: Monitor allocation rates per thread +- **Waste Analysis**: Identify threads with high TLAB waste ratios +- **Correlation**: Cross-reference TLAB data with memory leak patterns + +```bash +./profile-java-process.sh +# Select: 18. JFR Memory Leak Analysis with TLAB tracking +``` + +**🎯 Practical Exercise 4: Advanced JFR Analysis** + +1. **Execute TLAB tracking (10 minutes):** +```bash +./profile-java-process.sh +# Select option 18 +# Enter duration: 10 (minutes) +``` + +2. **Generate intensive allocation load:** +```bash +# High-frequency allocations to trigger TLAB behavior +for i in {1..1000}; do + curl -X POST http://localhost:8080/api/v1/objects/create + if [ $((i % 100)) -eq 0 ]; then + echo "Completed $i allocations" + fi +done +``` + +**Expected Results:** +``` +File: memory-leak-tlab-YYYYMMDD-HHMMSS.jfr +Analysis tools: JProfiler, VisualVM, Mission Control +Key insights: TLAB allocation patterns, object aging, GC behavior +``` + +--- + +## πŸ”₯ Flamegraph Interpretation Masterclass + +### Understanding Flamegraph Anatomy + +``` +β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” +β”‚ Stack Depth (Y-axis) - Call hierarchy depth β”‚ +β”‚ β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚ +β”‚ β”‚ main() ──────────────────────────────────────────── β”‚ β”‚ +β”‚ β”‚ └─ CocoController.createObject() ───────────────── β”‚ β”‚ +β”‚ β”‚ └─ ArrayList.add() ────────────────────────── β”‚ β”‚ +β”‚ β”‚ └─ MyPojo.() ───────────────────── β”‚ β”‚ +β”‚ β”‚ └─ String repetition ────────────── β”‚ β”‚ +β”‚ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚ +β”‚ Width (X-axis) - Time/Resource consumption β”‚ +β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ +``` + +### **Key Visual Patterns for Memory Leaks** + +#### **1. Wide Allocation Patterns** +``` +CocoController.createObject() β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ +└─ ArrayList.add() β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ + └─ MyPojo.() β–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆβ–ˆ +``` +**Interpretation:** Consistent, wide sections indicate high-frequency allocations + +#### **2. Growing Canvas Height** +``` +Run 1 (Baseline): Canvas height ~200px +Run 2 (5 minutes): Canvas height ~400px +Run 3 (10 minutes): Canvas height ~600px +``` +**Interpretation:** Increasing complexity suggests accumulating allocation paths + +#### **3. Stack Depth Patterns** +``` +Healthy Application: 3-5 levels deep +Memory Leak Pattern: 8-12 levels deep +Critical Leak: 15+ levels deep +``` + +### πŸ” Knowledge Check +**Look at your generated flamegraphs and answer:** +1. What is the canvas height of your memory-leak detection report? +2. Which method shows the widest section? +3. How many stack levels deep are the main allocation patterns? + +### **🎯 Practical Exercise 5: Comparative Flamegraph Analysis** + +1. **Generate multiple flamegraphs with different durations:** +```bash +# Short-term (30s) +./profile-java-process.sh # Option 2 + +# Medium-term (60s) +./profile-java-process.sh # Option 7, duration: 60 + +# Long-term (300s) +./profile-java-process.sh # Option 8 +``` + +2. **Create comparison table:** +```markdown +| Duration | Canvas Height | Widest Method | Stack Depth | File Size | +|----------|---------------|---------------|-------------|-----------| +| 30s | [measure] | [identify] | [count] | [size] | +| 60s | [measure] | [identify] | [count] | [size] | +| 300s | [measure] | [identify] | [count] | [size] | +``` + +3. **Document visual patterns:** +- Take screenshots of key sections +- Note color patterns and distributions +- Identify recurring allocation patterns + +--- + +## πŸŽ›οΈ JMeter Integration for Consistent Profiling + +### Understanding the Load Testing Integration + +The demo includes sophisticated JMeter integration for realistic profiling scenarios: + +```bash +# View available JMeter options +./run-jmeter.sh --help +``` + +**Key JMeter Parameters:** +- `-t, --time`: Test duration in seconds +- `-c, --concurrency`: Number of concurrent users +- `-r, --ramp-up`: Ramp-up time in seconds +- `-e, --endpoints`: Which endpoints to test (objects, threads, both) + +### **🎯 Practical Exercise 6: Advanced Load Testing Scenarios** + +#### **Scenario 1: Burst Load Testing** +```bash +# High concurrency, short duration +./run-jmeter.sh -t 120 -c 20 -r 10 -e both +``` +**Use case:** Simulating peak traffic conditions +**Profiling pairing:** Use with Option 2 (Memory Allocation) for burst pattern analysis + +#### **Scenario 2: Sustained Load Testing** +```bash +# Moderate concurrency, long duration +./run-jmeter.sh -t 600 -c 5 -r 30 -e objects +``` +**Use case:** Simulating normal production load +**Profiling pairing:** Use with Option 8 (Memory Leak Detection) for accumulation patterns + +#### **Scenario 3: Gradual Ramp Testing** +```bash +# Increasing load over time +./run-jmeter.sh -t 300 -c 10 -r 120 -e both +``` +**Use case:** Simulating growing user base +**Profiling pairing:** Use with Option 9 (Complete Workflow) for comprehensive analysis + +### **Creating Custom Load Patterns** + +```bash +# Create custom JMeter test plan +cat > custom-memory-leak-test.jmx << 'EOF' + + + + + + + + + objects_per_minute + 60 + + + + + + + +EOF +``` + +--- + +## πŸ“Š Evidence Collection and Documentation + +### Systematic Evidence Collection Framework + +For each profiling session, collect: + +#### **1. Technical Metrics** +```bash +# Create evidence collection script +cat > collect-evidence.sh << 'EOF' +#!/bin/bash +TIMESTAMP=$(date +%Y%m%d-%H%M%S) +EVIDENCE_DIR="profiler/evidence-$TIMESTAMP" +mkdir -p "$EVIDENCE_DIR" + +echo "Collecting evidence at $TIMESTAMP" + +# System information +echo "=== System Info ===" > "$EVIDENCE_DIR/system-info.txt" +java -version >> "$EVIDENCE_DIR/system-info.txt" 2>&1 +free -h >> "$EVIDENCE_DIR/system-info.txt" +nproc >> "$EVIDENCE_DIR/system-info.txt" + +# Application status +echo "=== App Status ===" > "$EVIDENCE_DIR/app-status.txt" +curl -s http://localhost:8080/actuator/health >> "$EVIDENCE_DIR/app-status.txt" +curl -s http://localhost:8080/actuator/metrics/jvm.memory.used >> "$EVIDENCE_DIR/app-status.txt" + +# Configuration +echo "=== Configuration ===" > "$EVIDENCE_DIR/config.txt" +curl -s http://localhost:8080/actuator/env/coco >> "$EVIDENCE_DIR/config.txt" + +echo "Evidence collected in $EVIDENCE_DIR" +EOF +chmod +x collect-evidence.sh +``` + +#### **2. Visual Documentation** +- Screenshot key flamegraph sections +- Document canvas heights and widths +- Note color patterns and distributions +- Capture browser developer tools memory graphs + +#### **3. Quantitative Measurements** +```bash +# Measure flamegraph characteristics +cat > measure-flamegraph.sh << 'EOF' +#!/bin/bash +HTML_FILE="$1" +if [ -z "$HTML_FILE" ]; then + echo "Usage: $0 " + exit 1 +fi + +echo "Analyzing flamegraph: $HTML_FILE" +echo "File size: $(wc -c < "$HTML_FILE") bytes" +echo "Estimated canvas height: $(grep -o 'height="[0-9]*"' "$HTML_FILE" | head -1 | grep -o '[0-9]*') pixels" +echo "Number of stack frames: $(grep -c 'class="func_g"' "$HTML_FILE")" +EOF +chmod +x measure-flamegraph.sh +``` + +--- + +## 🎯 Module 2 Assessment + +### Hands-on Proficiency Checklist + +**βœ… Interactive Script Mastery:** +- [ ] Successfully navigated all 21 profiling options +- [ ] Executed memory allocation profiling (Option 2) +- [ ] Completed 5-minute memory leak detection (Option 8) +- [ ] Generated complete memory analysis workflow (Option 9) +- [ ] Used advanced JFR analysis with TLAB tracking (Option 18) + +**βœ… Flamegraph Interpretation:** +- [ ] Can identify wide allocation patterns +- [ ] Measures canvas height accurately +- [ ] Counts stack depth levels +- [ ] Recognizes memory leak visual signatures + +**βœ… Load Testing Integration:** +- [ ] Executed coordinated JMeter load testing +- [ ] Created custom load patterns +- [ ] Synchronized profiling with realistic load +- [ ] Generated consistent, reproducible results + +**βœ… Evidence Collection:** +- [ ] Documented technical metrics for each session +- [ ] Captured visual evidence of flamegraph patterns +- [ ] Created quantitative measurements +- [ ] Organized evidence for systematic analysis + +### 🎯 Advanced Challenge: Custom Profiling Strategy + +**Challenge:** Design a custom profiling strategy for a specific memory leak scenario + +**Requirements:** +1. **Scenario Definition**: Define a specific memory leak pattern to investigate +2. **Tool Selection**: Choose appropriate profiling options from the 21 available +3. **Load Pattern**: Design matching JMeter load testing +4. **Evidence Plan**: Define what evidence to collect +5. **Success Criteria**: Establish measurable outcomes + +**Example Template:** +```markdown +# Custom Profiling Strategy: [Scenario Name] + +## Scenario +- **Leak Type**: [Collection/Thread Pool/Cache/etc.] +- **Symptoms**: [Expected behavior patterns] +- **Timeline**: [How long to observe] + +## Profiling Plan +- **Primary Tool**: Option X - [Name and rationale] +- **Supporting Tools**: Option Y, Z - [Supporting evidence] +- **Duration Strategy**: [Short/Medium/Long term analysis] + +## Load Testing +- **JMeter Configuration**: [Specific parameters] +- **Load Pattern**: [Burst/Sustained/Gradual] +- **Endpoint Focus**: [Which APIs to exercise] + +## Evidence Collection +- **Visual**: [What flamegraph patterns to document] +- **Quantitative**: [Specific metrics to measure] +- **Comparative**: [What to compare against] + +## Success Criteria +- [ ] [Measurable outcome 1] +- [ ] [Measurable outcome 2] +- [ ] [Measurable outcome 3] +``` + +--- + +## πŸš€ Transition to Module 3 + +**Excellent progress!** You've successfully: +- βœ… Mastered the 21-option interactive profiling script +- βœ… Generated comprehensive memory leak evidence +- βœ… Integrated realistic load testing with profiling +- βœ… Developed flamegraph interpretation skills +- βœ… Created systematic evidence collection processes + +### **What's Next?** +In **Module 3: Analysis and Evidence Collection**, we'll focus on: +- Systematic analysis using @162-java-profiling-analyze +- Creating structured documentation from profiling evidence +- Developing prioritized solution recommendations +- Cross-correlating multiple profiling results for comprehensive insights + +### πŸ’‘ Key Takeaway +**"Effective profiling is not just about collecting data - it's about collecting the RIGHT data under the RIGHT conditions to answer SPECIFIC questions about your application's performance!"** + +**Ready to transform your profiling data into actionable insights? [Let's continue to Module 3!](module-3-analysis.html) πŸ”** diff --git a/site-generator/content/courses/profile-memory-leak/module-3-analysis.md b/site-generator/content/courses/profile-memory-leak/module-3-analysis.md new file mode 100644 index 00000000..fea81e38 --- /dev/null +++ b/site-generator/content/courses/profile-memory-leak/module-3-analysis.md @@ -0,0 +1,608 @@ +title=Module 3: Analysis and Evidence Collection +type=course +status=published +date=2025-09-17 +author=Juan Antonio BreΓ±a Moral +version=0.11.0-SNAPSHOT +tags=java, profiling, memory-leak, analysis, evidence, documentation +~~~~~~ + +## Systematic Analysis using @162-java-profiling-analyze + +**⏱️ Duration:** 2 hours +**🎯 Learning Objectives:** +- Master the systematic analysis framework from @162-java-profiling-analyze +- Learn to categorize and prioritize performance issues using Impact/Effort scoring +- Create structured documentation following professional templates +- Develop cross-correlation analysis skills for multiple profiling results +- Generate actionable solution recommendations with implementation details + +--- + +## 🧠 The Systematic Analysis Framework + +### Understanding the @162-java-profiling-analyze Approach + +The analysis system prompt provides a **structured methodology** that transforms raw profiling data into actionable insights: + +``` +Raw Profiling Data β†’ Systematic Analysis β†’ Categorized Problems β†’ Prioritized Solutions +``` + +**Key Principles:** +1. **Problem-First Analysis**: Start with identifying specific issues, not just general observations +2. **Evidence-Based Documentation**: Every finding must reference specific profiling files and metrics +3. **Quantitative Assessment**: Use measurable criteria for impact and effort estimation +4. **Cross-Correlation**: Validate findings across multiple profiling sessions and file types + +### πŸ’‘ Learning Insight +**The difference between novice and expert performance analysis is systematic methodology. Random observations lead to random fixes - structured analysis leads to systematic improvements!** + +--- + +## πŸ“Š Step 1: Inventory and Organize Your Profiling Results + +### **🎯 Practical Exercise 1: Results Inventory** + +Let's organize the profiling data you've collected in Module 2: + +```bash +cd ./cursor-rules-java/examples/spring-boot-memory-leak-demo + +# Create organized analysis workspace +mkdir -p profiler/analysis-workspace +cd profiler/analysis-workspace + +# Inventory all available results +echo "=== PROFILING RESULTS INVENTORY ===" > results-inventory.md +echo "Generated on: $(date)" >> results-inventory.md +echo "" >> results-inventory.md + +# Categorize by file type +echo "## Memory Allocation Reports" >> results-inventory.md +ls -la ../results/allocation-flamegraph-*.html >> results-inventory.md 2>/dev/null || echo "None found" >> results-inventory.md + +echo "" >> results-inventory.md +echo "## Memory Leak Detection Reports" >> results-inventory.md +ls -la ../results/memory-leak-*.html >> results-inventory.md 2>/dev/null || echo "None found" >> results-inventory.md + +echo "" >> results-inventory.md +echo "## JFR Recording Files" >> results-inventory.md +ls -la ../results/*.jfr >> results-inventory.md 2>/dev/null || echo "None found" >> results-inventory.md + +echo "" >> results-inventory.md +echo "## Thread Dumps" >> results-inventory.md +ls -la ../results/threaddump-*.txt >> results-inventory.md 2>/dev/null || echo "None found" >> results-inventory.md + +echo "" >> results-inventory.md +echo "## GC Log Files" >> results-inventory.md +ls -la ../results/gc-*.log >> results-inventory.md 2>/dev/null || echo "None found" >> results-inventory.md + +cat results-inventory.md +``` + +### **File Organization Assessment** + +Create a systematic organization of your profiling evidence: + +```bash +# Create analysis directory structure +mkdir -p {evidence,analysis,solutions,reports} + +# Move/copy key files for analysis +cp ../results/memory-leak-*.html evidence/ 2>/dev/null || echo "No memory leak reports found" +cp ../results/allocation-flamegraph-*.html evidence/ 2>/dev/null || echo "No allocation reports found" +cp ../results/*.jfr evidence/ 2>/dev/null || echo "No JFR files found" + +# Create file manifest +ls -la evidence/ > file-manifest.txt +echo "Analysis workspace prepared with $(ls evidence/ | wc -l) evidence files" +``` + +--- + +## πŸ” Step 2: Problem Identification and Categorization + +### Memory-Related Issues Analysis Framework + +Based on the @162-java-profiling-analyze methodology, let's systematically analyze each type of issue: + +#### **🎯 Practical Exercise 2: Memory Leak Pattern Analysis** + +**Open your memory leak detection flamegraph:** +```bash +# Open the longest-duration memory leak report +LEAK_REPORT=$(ls evidence/memory-leak-*.html | tail -1) +echo "Analyzing: $LEAK_REPORT" + +# macOS +open "$LEAK_REPORT" + +# Linux +xdg-open "$LEAK_REPORT" +``` + +**Systematic Analysis Checklist:** + +1. **Visual Pattern Assessment:** +```markdown +## Memory Leak Visual Analysis + +### Canvas Characteristics +- **Canvas Height**: [measure in pixels] +- **Canvas Width**: [measure in pixels] +- **Overall Complexity**: [Low/Medium/High] + +### Stack Depth Analysis +- **Maximum Stack Depth**: [count levels] +- **Average Stack Depth**: [estimate] +- **Deep Stack Patterns**: [identify methods with >10 levels] + +### Width Distribution Patterns +- **Widest Method**: [identify method name] +- **Width Percentage**: [estimate % of total width] +- **Consistent Wide Patterns**: [list recurring wide sections] +``` + +2. **Quantitative Measurements:** +```bash +# Create measurement script +cat > measure-flamegraph.sh << 'EOF' +#!/bin/bash +HTML_FILE="$1" +if [ -z "$HTML_FILE" ]; then + echo "Usage: $0 " + exit 1 +fi + +echo "=== FLAMEGRAPH MEASUREMENTS ===" +echo "File: $(basename "$HTML_FILE")" +echo "Size: $(wc -c < "$HTML_FILE") bytes" +echo "Generated: $(stat -c %y "$HTML_FILE" 2>/dev/null || stat -f %Sm "$HTML_FILE")" + +# Extract technical details from HTML +echo "Canvas height: $(grep -o 'height="[0-9]*"' "$HTML_FILE" | head -1 | grep -o '[0-9]*') pixels" +echo "Stack frames: $(grep -c 'class="func_g"' "$HTML_FILE") elements" +echo "Text elements: $(grep -c '1000 frames)" +elif [ "$FRAMES" -gt 500 ]; then + echo "Complexity: MEDIUM (500-1000 frames)" +else + echo "Complexity: LOW (<500 frames)" +fi +EOF +chmod +x measure-flamegraph.sh + +# Measure all your flamegraphs +for file in evidence/*.html; do + ./measure-flamegraph.sh "$file" + echo "---" +done +``` + +### **🎯 Practical Exercise 3: Cross-File Correlation Analysis** + +Compare patterns across different profiling sessions: + +```bash +# Create correlation analysis +cat > correlation-analysis.md << 'EOF' +# Cross-File Correlation Analysis + +## Allocation vs Leak Detection Comparison + +| Metric | 30s Allocation | 5min Leak Detection | Correlation | +|--------|----------------|-------------------|-------------| +| Canvas Height | [measure] | [measure] | [growing/stable/shrinking] | +| Widest Method | [identify] | [identify] | [same/different] | +| Stack Complexity | [count] | [count] | [increasing/stable] | +| File Size | [bytes] | [bytes] | [ratio] | + +## Pattern Consistency Analysis + +### Recurring Allocation Patterns +- [ ] CocoController.createObject appears in all reports +- [ ] ArrayList.add shows consistent width +- [ ] MyPojo allocation patterns are reproducible +- [ ] String operations show expected behavior + +### Temporal Pattern Changes +- [ ] Short-term reports show basic patterns +- [ ] Long-term reports show accumulation +- [ ] Stack depth increases over time +- [ ] Method width consistency maintained + +## Evidence Correlation Score +- **Strong Correlation (3/3)**: Patterns consistent across all timeframes +- **Moderate Correlation (2/3)**: Some variations but clear trends +- **Weak Correlation (1/3)**: Inconsistent patterns, need more data +EOF + +# Fill in the template with your actual measurements +echo "Edit correlation-analysis.md with your specific measurements" +``` + +--- + +## πŸ“ Step 3: Structured Documentation Creation + +### **Creating the Problem Analysis Document** + +Following the @162-java-profiling-analyze template: + +```bash +# Create the problem analysis document +DATE_SUFFIX=$(date +%Y%m%d) +cat > analysis/profiling-problem-analysis-${DATE_SUFFIX}.md << 'EOF' +# Profiling Problem Analysis - [DATE] + +## Executive Summary +- **Analysis Date**: [Current Date] +- **Application**: Spring Boot Memory Leak Demo +- **Configuration**: coco=true (memory leaks enabled) +- **Profiling Duration**: [Total time spent profiling] +- **Severity Classification**: CRITICAL - Active memory leaks detected +- **Impact Assessment**: Memory exhaustion risk under sustained load + +## Detailed Findings + +### 1. Unbounded Object Accumulation (CRITICAL) +- **Description**: CocoController.createObject() method continuously adds objects to ArrayList without bounds checking +- **Evidence**: + - File: `memory-leak-YYYYMMDD-HHMMSS.html` + - Pattern: Consistent wide sections in CocoController allocation paths + - Measurement: Canvas height [X] pixels, [Y] stack frames +- **Impact**: Linear memory growth leading to eventual OutOfMemoryError +- **Root Cause**: Missing collection size limits and cleanup logic + +### 2. Thread Pool Resource Leaks (HIGH) +- **Description**: ExecutorService instances created without proper lifecycle management +- **Evidence**: + - File: `allocation-flamegraph-YYYYMMDD-HHMMSS.html` + - Pattern: Thread creation patterns without corresponding cleanup + - Measurement: [X] thread-related allocations detected +- **Impact**: Thread pool exhaustion and native memory leaks +- **Root Cause**: Missing @PreDestroy cleanup and shared resource management + +### 3. String Allocation Inefficiencies (MEDIUM) +- **Description**: Repeated string operations creating unnecessary object allocations +- **Evidence**: + - File: `memory-leak-YYYYMMDD-HHMMSS.html` + - Pattern: String concatenation and repetition in MyPojo constructor + - Measurement: [X]% of allocations attributed to String operations +- **Impact**: Increased GC pressure and memory churn +- **Root Cause**: Inefficient string handling in object initialization + +## Methodology +- **Profiling Tools Used**: async-profiler v4.1, JFR analysis +- **Data Collection Approach**: Multi-duration analysis (30s, 5min, comprehensive workflow) +- **Load Testing**: JMeter coordinated load testing for realistic conditions +- **Analysis Techniques Applied**: Flamegraph visual analysis, quantitative measurements, cross-correlation + +## Recommendations Priority +1. **CRITICAL (Immediate)**: Implement collection bounds and thread pool lifecycle management +2. **HIGH (This Sprint)**: Add resource cleanup patterns and monitoring +3. **MEDIUM (Next Sprint)**: Optimize string operations and allocation patterns +4. **LOW (Future)**: Performance monitoring and alerting infrastructure + +## Supporting Evidence Files +- Memory leak detection: `../evidence/memory-leak-*.html` +- Allocation analysis: `../evidence/allocation-flamegraph-*.html` +- JFR recordings: `../evidence/*.jfr` +- Measurements: `../correlation-analysis.md` + +## Next Steps +1. Proceed to solution development (Module 4) +2. Implement fixes using coco=false configuration +3. Validate improvements through comparative analysis (Module 5) +EOF + +echo "Problem analysis document created: analysis/profiling-problem-analysis-${DATE_SUFFIX}.md" +echo "Please edit the template with your specific measurements and findings" +``` + +### **🎯 Practical Exercise 4: Impact/Effort Prioritization** + +Implement the Impact/Effort scoring framework: + +```bash +# Create prioritization analysis +cat > analysis/impact-effort-prioritization.md << 'EOF' +# Impact/Effort Prioritization Analysis + +## Scoring Framework +- **Impact Score (1-5)**: 5=Critical performance degradation, 1=Cosmetic optimization +- **Effort Score (1-5)**: 1=Configuration change, 5=Architecture change +- **Priority = Impact / Effort**: Higher scores = Higher priority + +## Issue Prioritization Matrix + +| Issue | Impact | Effort | Priority | Rationale | +|-------|---------|--------|----------|-----------| +| Unbounded Collections | 5 | 1 | 5.0 | Critical leak, config change fix | +| Thread Pool Leaks | 4 | 2 | 2.0 | High impact, moderate refactoring | +| String Inefficiencies | 2 | 3 | 0.67 | Low impact, requires code changes | +| Missing Monitoring | 3 | 2 | 1.5 | Medium impact, setup required | + +## Implementation Order +1. **Priority 5.0**: Unbounded Collections (Immediate - configuration change) +2. **Priority 2.0**: Thread Pool Leaks (This week - class refactoring) +3. **Priority 1.5**: Missing Monitoring (Next week - infrastructure setup) +4. **Priority 0.67**: String Inefficiencies (Future - performance optimization) + +## Resource Allocation +- **Week 1**: Focus on Priority 5.0 and 2.0 items (80% of impact with 20% of effort) +- **Week 2**: Address monitoring and validation +- **Week 3+**: Performance optimizations and enhancements +EOF + +echo "Prioritization analysis created" +``` + +--- + +## 🎯 Step 4: Solution Development Framework + +### **Creating the Solutions Document** + +```bash +# Create comprehensive solutions document +DATE_SUFFIX=$(date +%Y%m%d) +cat > solutions/profiling-solutions-${DATE_SUFFIX}.md << 'EOF' +# Profiling Solutions and Recommendations - [DATE] + +## Quick Wins (Low effort, High impact) + +### Solution 1: Enable Fixed Controller Implementation +- **Problem**: Critical memory leaks in CocoController causing unbounded growth +- **Solution**: Switch to NoCocoController using coco=false configuration +- **Expected Impact**: Eliminate memory leaks immediately, stabilize memory usage +- **Implementation Effort**: 5 minutes (configuration change) +- **Code Changes**: + ```properties + # application.properties + coco=false + ``` +- **Validation**: Memory usage should stabilize within 30 minutes of change + +### Solution 2: Implement Collection Bounds +- **Problem**: ArrayList grows without limits leading to memory exhaustion +- **Solution**: Add MAX_OBJECTS constant and bounds checking +- **Expected Impact**: Cap memory usage, provide graceful degradation +- **Implementation Effort**: 30 minutes (add bounds checking) +- **Code Changes**: + ```java + private static final int MAX_OBJECTS = 10000; + + if (objects.size() >= MAX_OBJECTS) { + return ResponseEntity.badRequest() + .body("Maximum objects limit reached: " + MAX_OBJECTS); + } + ``` + +## Medium-term Improvements + +### Solution 3: Thread Pool Lifecycle Management +- **Problem**: ExecutorService instances created without cleanup +- **Solution**: Implement shared thread pool with proper @PreDestroy cleanup +- **Expected Impact**: Eliminate thread leaks, reduce resource overhead by 90% +- **Implementation Effort**: 2 hours (class refactoring) +- **Code Changes**: Already implemented in NoCocoController + ```java + private final ExecutorService sharedExecutorService = + Executors.newFixedThreadPool(10, new CustomizableThreadFactory("shared-pool-")); + + @PreDestroy + public void cleanup() throws InterruptedException { + sharedExecutorService.shutdown(); + if (!sharedExecutorService.awaitTermination(30, TimeUnit.SECONDS)) { + sharedExecutorService.shutdownNow(); + } + } + ``` + +## Long-term Optimizations + +### Solution 4: Performance Monitoring Infrastructure +- **Problem**: No early warning system for memory leaks +- **Solution**: Implement comprehensive memory monitoring and alerting +- **Expected Impact**: Prevent future memory leak incidents +- **Implementation Effort**: 1 day (monitoring setup) +- **Code Changes**: JVM monitoring flags and dashboard configuration + +## Implementation Plan + +### Phase 1: Emergency Response (Next Hour) +1. **Immediate**: Switch to coco=false configuration +2. **Validation**: Run 30-minute stability test +3. **Verification**: Confirm memory usage stabilizes + +### Phase 2: Stabilization (Next 24 Hours) +1. **Deploy monitoring**: Implement memory usage alerts +2. **Load testing**: Run sustained load test to verify fix +3. **Documentation**: Update analysis with results + +### Phase 3: Prevention (Next Week) +1. **Process improvement**: Add profiling to CI/CD pipeline +2. **Team training**: Review memory leak detection procedures +3. **Monitoring enhancement**: Create comprehensive performance dashboard + +## Success Criteria + +### Immediate Success (1 Hour) +- [ ] Memory usage stabilizes below baseline +- [ ] No memory growth under 30-minute load test +- [ ] Application remains responsive + +### Short-term Success (24 Hours) +- [ ] Memory patterns remain stable over 6-hour test +- [ ] GC frequency within acceptable limits +- [ ] Response times meet SLA requirements + +### Long-term Success (1 Week) +- [ ] No memory leaks detected in continuous profiling +- [ ] Performance monitoring alerts configured +- [ ] Team knowledge transfer completed + +## Risk Mitigation +- **Deployment Risk**: Use feature flags for gradual rollout +- **Performance Risk**: Comprehensive load testing before production +- **Regression Risk**: Automated profiling in CI/CD pipeline +EOF + +echo "Solutions document created: solutions/profiling-solutions-${DATE_SUFFIX}.md" +``` + +--- + +## πŸ“Š Step 5: Cross-Correlation and Validation + +### **🎯 Practical Exercise 5: Multi-Source Evidence Correlation** + +Create a comprehensive evidence correlation matrix: + +```bash +# Create evidence correlation analysis +cat > analysis/evidence-correlation-matrix.md << 'EOF' +# Evidence Correlation Matrix + +## Data Source Cross-Validation + +### Flamegraph Evidence Consistency +| Evidence Type | File 1 | File 2 | File 3 | Consistency Score | +|---------------|---------|--------|--------|------------------| +| Allocation Patterns | CocoController.createObject | [same/different] | [same/different] | [3/3, 2/3, 1/3] | +| Stack Depth | [X levels] | [Y levels] | [Z levels] | [growing/stable/shrinking] | +| Method Width | [X% canvas] | [Y% canvas] | [Z% canvas] | [consistent/variable] | + +### Temporal Pattern Validation +| Time Period | Memory Growth | GC Pressure | Thread Creation | Validation | +|-------------|---------------|-------------|-----------------|------------| +| 0-30s | [baseline] | [normal] | [initial] | βœ… Expected | +| 30s-5min | [growing] | [increasing] | [accumulating] | βœ… Leak confirmed | +| 5min+ | [critical] | [high] | [excessive] | βœ… Critical state | + +### Load Testing Correlation +| Load Pattern | Memory Impact | Expected Behavior | Actual Behavior | Match | +|-------------|---------------|-------------------|-----------------|-------| +| Burst Load | High allocation spike | βœ… Confirmed | [your observation] | [βœ…/❌] | +| Sustained Load | Linear growth | βœ… Confirmed | [your observation] | [βœ…/❌] | +| No Load | Stable baseline | βœ… Confirmed | [your observation] | [βœ…/❌] | + +## Confidence Assessment +- **High Confidence (3/3 sources agree)**: [List findings with high confidence] +- **Medium Confidence (2/3 sources agree)**: [List findings with medium confidence] +- **Low Confidence (1/3 sources agree)**: [List findings requiring more investigation] + +## Recommendation Validation +- **Strongly Supported**: Solutions backed by multiple evidence sources +- **Moderately Supported**: Solutions backed by primary evidence +- **Weakly Supported**: Solutions requiring additional validation +EOF + +echo "Fill in the correlation matrix with your specific observations" +``` + +--- + +## 🎯 Module 3 Assessment + +### Comprehensive Analysis Checklist + +**βœ… Systematic Analysis Mastery:** +- [ ] Completed results inventory and organization +- [ ] Applied structured problem identification framework +- [ ] Created quantitative measurements for all flamegraphs +- [ ] Performed cross-file correlation analysis +- [ ] Documented findings using professional templates + +**βœ… Documentation Excellence:** +- [ ] Created problem analysis document following template +- [ ] Developed prioritized solutions with Impact/Effort scoring +- [ ] Generated implementation plan with timeline +- [ ] Established success criteria and validation methods + +**βœ… Evidence-Based Reasoning:** +- [ ] Every finding references specific profiling files +- [ ] Quantitative metrics support all conclusions +- [ ] Cross-correlation validates findings across multiple sources +- [ ] Confidence levels assigned to each recommendation + +**βœ… Professional Communication:** +- [ ] Executive summary suitable for management +- [ ] Technical details appropriate for development team +- [ ] Implementation guidance actionable and specific +- [ ] Risk assessment and mitigation strategies included + +### 🎯 Advanced Challenge: Comprehensive Analysis Report + +**Challenge:** Create a complete analysis package suitable for presentation to senior management and development teams. + +**Requirements:** +1. **Executive Presentation**: 3-slide summary of critical findings +2. **Technical Deep-dive**: Complete analysis with all supporting evidence +3. **Implementation Roadmap**: Detailed timeline with resource requirements +4. **ROI Analysis**: Quantified impact of proposed solutions +5. **Risk Assessment**: Comprehensive risk analysis with mitigation strategies + +**Deliverables:** +```bash +# Create final analysis package +mkdir -p reports/final-analysis-package +cd reports/final-analysis-package + +# Copy all analysis documents +cp ../../analysis/* . +cp ../../solutions/* . + +# Create executive summary +cat > executive-summary.md << 'EOF' +# Executive Summary: Memory Leak Analysis + +## Critical Findings +- **Issue**: Active memory leaks causing 318% memory retention increase +- **Impact**: Application will crash under sustained production load +- **Solution**: Configuration change can resolve immediately (5-minute fix) +- **Investment**: Minimal effort, maximum impact + +## Recommended Action +1. **Immediate**: Deploy coco=false configuration (5 minutes) +2. **Short-term**: Implement monitoring and validation (1 day) +3. **Long-term**: Enhance performance monitoring (1 week) + +## Business Impact +- **Risk Mitigation**: Prevent production outages +- **Performance**: Improve application stability +- **Cost**: Minimal development investment +- **Timeline**: Issue resolved within 1 hour +EOF + +echo "Final analysis package created in reports/final-analysis-package/" +``` + +--- + +## πŸš€ Transition to Module 4 + +**Outstanding work!** You've successfully: +- βœ… Applied systematic analysis methodology from @162-java-profiling-analyze +- βœ… Created comprehensive problem documentation with quantitative evidence +- βœ… Developed prioritized solutions using Impact/Effort framework +- βœ… Performed cross-correlation analysis across multiple data sources +- βœ… Generated professional-grade analysis reports + +### **What's Next?** +In **Module 4: Refactoring and Solution Implementation**, we'll focus on: +- Implementing the prioritized solutions you've identified +- Using the coco=false configuration to resolve memory leaks +- Validating that fixes are properly applied and effective +- Setting up monitoring and alerting for ongoing protection + +### πŸ’‘ Key Takeaway +**"Systematic analysis transforms raw profiling data into actionable business intelligence. Your structured approach ensures that performance improvements are based on evidence, prioritized by impact, and communicated effectively to all stakeholders!"** + +**Ready to implement your solutions and see the memory leaks disappear? [Let's continue to Module 4!](module-4-refactoring.html) πŸ› οΈ** diff --git a/site-generator/content/courses/profile-memory-leak/module-4-refactoring.md b/site-generator/content/courses/profile-memory-leak/module-4-refactoring.md new file mode 100644 index 00000000..ed5681a1 --- /dev/null +++ b/site-generator/content/courses/profile-memory-leak/module-4-refactoring.md @@ -0,0 +1,597 @@ +title=Module 4: Refactoring and Solution Implementation +type=course +status=published +date=2025-09-17 +author=Juan Antonio BreΓ±a Moral +version=0.11.0-SNAPSHOT +tags=java, profiling, memory-leak, refactoring, implementation, validation +~~~~~~ + +## Implementing Memory Leak Fixes and Validation + +**⏱️ Duration:** 2 hours +**🎯 Learning Objectives:** +- Implement the prioritized solutions identified in Module 3 +- Understand the `coco=false` configuration pattern for immediate leak resolution +- Understand proper resource lifecycle management patterns +- Validate that fixes are correctly applied and effective +- Set up monitoring and alerting for ongoing protection + +--- + +## πŸš€ Implementation Strategy Overview + +### The Three-Phase Implementation Approach + +Based on your analysis from Module 3, we'll implement solutions in priority order: + +1. **Phase 1: Emergency Response (5 minutes)** - Configuration change for immediate relief +2. **Phase 2: Validation and Monitoring (30 minutes)** - Verify fixes and establish monitoring +3. **Phase 3: Long-term Improvements (1 hour)** - Enhanced patterns and prevention + +### πŸ’‘ Learning Insight +**The beauty of the `coco=false` pattern is that it demonstrates the complete solution already implemented in `NoCocoController`. This allows you to see the "after" state immediately while learning the specific patterns that prevent memory leaks!** + +--- + +## ⚑ Phase 1: Emergency Response - Configuration Change + +### **🎯 Practical Exercise 1: Immediate Memory Leak Resolution** + +Let's implement the highest-priority solution with immediate impact: + +#### **Step 1: Verify Current Configuration** +```bash +cd ./cursor-rules-java/examples/spring-boot-memory-leak-demo + +# Check current configuration +echo "=== Current Configuration Status ===" +curl -s http://localhost:8080/actuator/env/coco | grep -E '"value"|"name"' + +# Verify which controller is active by testing endpoints +echo "=== Testing Current Controller ===" +RESPONSE=$(curl -s -X POST http://localhost:8080/api/v1/objects/create) +echo "Object creation response: $RESPONSE" + +# Check current memory usage +echo "=== Current Memory Usage ===" +curl -s http://localhost:8080/actuator/metrics/jvm.memory.used | grep -E '"name"|"value"' +``` + +#### **Step 2: Apply the Configuration Change** + +**Method 1: Runtime Configuration Override (Immediate)** +```bash +# Stop the current application +# Press Ctrl+C in the terminal running the application + +# Restart with coco=false +echo "Starting application with memory leak fixes enabled..." +./run-java-process-for-profiling.sh --profile vt +# This uses the application-vt.properties profile which has coco=false +``` + +**Method 2: Direct Configuration File Edit (Permanent)** +```bash +# Edit the main configuration file +cp src/main/resources/application.properties src/main/resources/application.properties.backup + +# Change the configuration +sed -i.bak 's/coco=true/coco=false/' src/main/resources/application.properties + +# Verify the change +echo "=== Configuration Change Applied ===" +grep coco src/main/resources/application.properties + +# Restart application +./run-java-process-for-profiling.sh +``` + +#### **Step 3: Immediate Validation** +```bash +# Wait for application startup (30 seconds) +sleep 30 + +# Verify the configuration change took effect +echo "=== Post-Change Configuration Verification ===" +curl -s http://localhost:8080/actuator/env/coco + +# Test that fixed controller is now active +echo "=== Testing Fixed Controller ===" +for i in {1..5}; do + RESPONSE=$(curl -s -X POST http://localhost:8080/api/v1/objects/create) + echo "Test $i: $RESPONSE" +done + +# Verify bounds checking is working +echo "=== Testing Bounds Protection ===" +# The fixed controller has MAX_OBJECTS=10000, but we can test the pattern +curl -s -X POST http://localhost:8080/api/v1/objects/create | grep -E "created|limit" +``` + +### **πŸ” Understanding the Fix: Code Comparison** + +Let's examine exactly what changed: + +```bash +# View the problematic implementation +echo "=== PROBLEMATIC IMPLEMENTATION (CocoController) ===" +grep -A 10 -B 2 "createObject" src/main/java/info/jab/ms/CocoController.java + +echo "" +echo "=== FIXED IMPLEMENTATION (NoCocoController) ===" +grep -A 15 -B 2 "createObject" src/main/java/info/jab/ms/NoCocoController.java +``` + +**Key Differences Analysis:** + +**Collection Bounds:** + - CocoController (Problematic): `objects.add(new MyPojo(...))` + - NoCocoController (Fixed): `if (objects.size() >= MAX_OBJECTS)` bounds check +**Error Handling:** + - CocoController (Problematic): No bounds validation + - NoCocoController (Fixed): Returns `400 Bad Request` when limit reached +**Thread Management:** + - CocoController (Problematic): `Executors.newFixedThreadPool(5)` per request + - NoCocoController (Fixed): Shared `ExecutorService` with lifecycle +**Resource Cleanup:** + - CocoController (Problematic): No cleanup logic + - NoCocoController (Fixed): `@PreDestroy` method with proper shutdown +**Thread Safety:** + - CocoController (Problematic): Basic `ArrayList` + - NoCocoController (Fixed): `Collections.synchronizedList` + +### πŸ’‘ Learning Reinforcement +**Notice how the fixed implementation follows enterprise patterns: bounded collections, shared resources, lifecycle management, and graceful error handling. These aren't just memory leak fixes - they're production-ready design patterns!** + +--- + +## πŸ” Phase 2: Validation and Monitoring + +### **🎯 Practical Exercise 2: Comprehensive Fix Validation** + +#### **Step 1: Functional Validation** +```bash +# Create comprehensive validation script +cat > validate-fixes.sh << 'EOF' +#!/bin/bash +echo "=== MEMORY LEAK FIX VALIDATION ===" +echo "Timestamp: $(date)" +echo "" + +# Test 1: Configuration verification +echo "1. Configuration Status:" +CONFIG_RESPONSE=$(curl -s http://localhost:8080/actuator/env/coco) +echo "$CONFIG_RESPONSE" | grep -E '"value"|"name"' | head -2 + +# Test 2: Bounds checking validation +echo "" +echo "2. Bounds Checking Test:" +for i in {1..10}; do + RESPONSE=$(curl -s -X POST http://localhost:8080/api/v1/objects/create) + echo " Request $i: $RESPONSE" +done + +# Test 3: Thread creation test +echo "" +echo "3. Thread Management Test:" +for i in {1..5}; do + THREAD_RESPONSE=$(curl -s -X POST http://localhost:8080/api/v1/threads/create) + echo " Thread test $i: $THREAD_RESPONSE" +done + +# Test 4: Memory usage baseline +echo "" +echo "4. Memory Usage Check:" +MEMORY_USED=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.used) +echo "$MEMORY_USED" | grep -E '"value"' | head -1 + +# Test 5: Application health +echo "" +echo "5. Application Health:" +HEALTH=$(curl -s http://localhost:8080/actuator/health) +echo "$HEALTH" + +echo "" +echo "=== VALIDATION COMPLETE ===" +EOF +chmod +x validate-fixes.sh + +# Run validation +./validate-fixes.sh +``` + +#### **Step 2: Load Testing Validation** +```bash +# Run sustained load test to verify stability +echo "=== SUSTAINED LOAD TEST ===" +echo "Running 10-minute stability test..." + +# Start JMeter load test +./run-jmeter.sh -t 600 -c 3 -e both & +JMETER_PID=$! + +# Monitor memory usage during load test +echo "Monitoring memory usage every 30 seconds..." +for i in {1..20}; do + TIMESTAMP=$(date '+%H:%M:%S') + MEMORY=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.used | grep -o '"value":[0-9]*' | grep -o '[0-9]*') + echo "$TIMESTAMP: Memory used: $MEMORY bytes" + sleep 30 +done + +# Wait for JMeter to complete +wait $JMETER_PID +echo "Load test completed successfully" +``` + +#### **Step 3: Comparative Memory Analysis** +```bash +# Generate post-fix profiling data for comparison +echo "=== GENERATING POST-FIX PROFILING DATA ===" + +cd profiler/scripts +./profile-java-process.sh +# Select: 2. Memory Allocation Profiling (30s) +# This will generate new flamegraphs with the fixes applied + +# Generate load during profiling +cd ../.. +for i in {1..50}; do + curl -s -X POST http://localhost:8080/api/v1/objects/create > /dev/null + curl -s -X POST http://localhost:8080/api/v1/threads/create > /dev/null + sleep 1 +done + +echo "Post-fix profiling data generated" +``` + +--- + +## πŸ› οΈ Phase 3: Understanding the Implementation Patterns + +### **Resource Lifecycle Management Deep Dive** + +Let's examine the specific patterns that prevent memory leaks: + +#### **🎯 Practical Exercise 3: Code Pattern Analysis** + +```bash +# Extract and analyze the key patterns +echo "=== RESOURCE LIFECYCLE PATTERNS ===" + +# Pattern 1: Bounded Collections +echo "1. Bounded Collection Pattern:" +grep -A 5 -B 2 "MAX_OBJECTS" src/main/java/info/jab/ms/NoCocoController.java + +echo "" +echo "2. Thread Pool Management Pattern:" +grep -A 10 -B 2 "sharedExecutorService" src/main/java/info/jab/ms/NoCocoController.java + +echo "" +echo "3. Resource Cleanup Pattern:" +grep -A 10 -B 2 "@PreDestroy" src/main/java/info/jab/ms/NoCocoController.java +``` + +#### **Understanding Each Pattern** + +**1. Bounded Collections Pattern:** +```java +private static final int MAX_OBJECTS = 10000; +private final List objects = Collections.synchronizedList(new ArrayList<>()); + +@PostMapping("/objects/create") +public ResponseEntity createObject() { + if (objects.size() >= MAX_OBJECTS) { + return ResponseEntity.badRequest() + .body("Maximum objects limit reached: " + MAX_OBJECTS); + } + objects.add(new MyPojo(UUID.randomUUID().toString(), + "A".repeat(1000), + System.currentTimeMillis())); + return ResponseEntity.ok("Object created: " + objects.size()); +} +``` + +**Key Benefits:** +- βœ… **Memory Protection**: Prevents unbounded growth +- βœ… **Graceful Degradation**: Returns meaningful error instead of crashing +- βœ… **Thread Safety**: Uses synchronized wrapper for concurrent access +- βœ… **Monitoring**: Provides current count for observability + +**2. Shared Thread Pool Pattern:** +```java +private final ExecutorService sharedExecutorService = + Executors.newFixedThreadPool(10, new CustomizableThreadFactory("shared-pool-")); + +@PostMapping("/threads/create") +public ResponseEntity createThread() { + sharedExecutorService.submit(() -> { + try { + Thread.sleep(1000); + log.info("Task executed in thread: {}", Thread.currentThread().getName()); + } catch (InterruptedException e) { + Thread.currentThread().interrupt(); + } + }); + return ResponseEntity.ok("Task submitted to shared thread pool"); +} +``` + +**Key Benefits:** +- βœ… **Resource Efficiency**: Single shared pool vs. multiple pools +- βœ… **Lifecycle Management**: Proper initialization and cleanup +- βœ… **Named Threads**: CustomizableThreadFactory for debugging +- βœ… **Interruption Handling**: Proper interrupt signal management + +**3. Resource Cleanup Pattern:** +```java +@PreDestroy +public void cleanup() throws InterruptedException { + log.info("Shutting down shared executor service..."); + sharedExecutorService.shutdown(); + + if (!sharedExecutorService.awaitTermination(30, TimeUnit.SECONDS)) { + log.warn("Executor did not terminate gracefully, forcing shutdown..."); + sharedExecutorService.shutdownNow(); + + if (!sharedExecutorService.awaitTermination(10, TimeUnit.SECONDS)) { + log.error("Executor did not terminate after forced shutdown"); + } + } + log.info("Shared executor service shutdown complete"); +} +``` + +**Key Benefits:** +- βœ… **Graceful Shutdown**: Allows running tasks to complete +- βœ… **Timeout Protection**: Forces shutdown if graceful fails +- βœ… **Logging**: Provides visibility into shutdown process +- βœ… **Resource Guarantee**: Ensures threads are properly cleaned up + +### πŸ’‘ Learning Reinforcement +**These patterns represent enterprise-grade resource management. The `@PreDestroy` pattern is especially important - it's Spring's way of ensuring cleanup happens during application shutdown, preventing resource leaks even during deployment cycles!** + +--- + +## πŸ“Š Monitoring and Alerting Setup + +### **🎯 Practical Exercise 4: Implementing Memory Monitoring** + +#### **Step 1: JVM Monitoring Configuration** +```bash +# Add comprehensive JVM monitoring flags +cat > monitoring-flags.txt << 'EOF' +# Memory Monitoring JVM Flags +-XX:+PrintGC +-XX:+PrintGCDetails +-XX:+PrintGCTimeStamps +-XX:+PrintGCApplicationStoppedTime +-Xloggc:gc-monitoring.log +-XX:+UseGCLogFileRotation +-XX:NumberOfGCLogFiles=5 +-XX:GCLogFileSize=10M + +# Memory Dump on OutOfMemoryError +-XX:+HeapDumpOnOutOfMemoryError +-XX:HeapDumpPath=./memory-dumps/ + +# JFR Continuous Profiling +-XX:+FlightRecorder +-XX:StartFlightRecording=duration=1h,filename=continuous-monitoring.jfr,settings=profile +EOF + +echo "Monitoring configuration created. Add these flags to your startup script." +``` + +#### **Step 2: Application Metrics Monitoring** +```bash +# Create memory monitoring script +cat > monitor-memory.sh << 'EOF' +#!/bin/bash +MONITOR_DURATION=${1:-300} # Default 5 minutes +INTERVAL=${2:-10} # Default 10 seconds + +echo "=== MEMORY MONITORING ===" +echo "Duration: $MONITOR_DURATION seconds" +echo "Interval: $INTERVAL seconds" +echo "Timestamp,HeapUsed,HeapMax,NonHeapUsed,ObjectCount" > memory-monitor.csv + +START_TIME=$(date +%s) +END_TIME=$((START_TIME + MONITOR_DURATION)) + +while [ $(date +%s) -lt $END_TIME ]; do + TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S') + + # Get heap memory usage + HEAP_USED=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.used?tag=area:heap | grep -o '"value":[0-9]*' | grep -o '[0-9]*') + HEAP_MAX=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.max?tag=area:heap | grep -o '"value":[0-9]*' | grep -o '[0-9]*') + + # Get non-heap memory usage + NONHEAP_USED=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.used?tag=area:nonheap | grep -o '"value":[0-9]*' | grep -o '[0-9]*') + + # Get object count from our controller + OBJECT_RESPONSE=$(curl -s -X POST http://localhost:8080/api/v1/objects/create) + OBJECT_COUNT=$(echo "$OBJECT_RESPONSE" | grep -o '[0-9]*$' || echo "0") + + # Log to CSV + echo "$TIMESTAMP,$HEAP_USED,$HEAP_MAX,$NONHEAP_USED,$OBJECT_COUNT" >> memory-monitor.csv + + # Display current status + HEAP_PCT=$((HEAP_USED * 100 / HEAP_MAX)) + echo "[$TIMESTAMP] Heap: ${HEAP_PCT}% ($HEAP_USED/$HEAP_MAX bytes), Objects: $OBJECT_COUNT" + + sleep $INTERVAL +done + +echo "Monitoring complete. Data saved to memory-monitor.csv" +EOF +chmod +x monitor-memory.sh + +# Run monitoring during load test +echo "Starting memory monitoring with load test..." +./monitor-memory.sh 300 15 & # 5 minutes, 15-second intervals +MONITOR_PID=$! + +# Generate load during monitoring +for i in {1..100}; do + curl -s -X POST http://localhost:8080/api/v1/objects/create > /dev/null + sleep 3 +done + +wait $MONITOR_PID +echo "Memory monitoring completed" +``` + +#### **Step 3: Alerting Thresholds** +```bash +# Create alerting configuration +cat > memory-alerts.sh << 'EOF' +#!/bin/bash +# Memory alerting script + +HEAP_THRESHOLD=80 # Alert when heap usage > 80% +OBJECT_THRESHOLD=9000 # Alert when objects > 9000 + +check_memory_usage() { + HEAP_USED=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.used?tag=area:heap | grep -o '"value":[0-9]*' | grep -o '[0-9]*') + HEAP_MAX=$(curl -s http://localhost:8080/actuator/metrics/jvm.memory.max?tag=area:heap | grep -o '"value":[0-9]*' | grep -o '[0-9]*') + + if [ -n "$HEAP_USED" ] && [ -n "$HEAP_MAX" ]; then + HEAP_PCT=$((HEAP_USED * 100 / HEAP_MAX)) + + if [ $HEAP_PCT -gt $HEAP_THRESHOLD ]; then + echo "ALERT: Heap usage at ${HEAP_PCT}% (threshold: ${HEAP_THRESHOLD}%)" + return 1 + fi + fi + + return 0 +} + +check_object_count() { + OBJECT_RESPONSE=$(curl -s -X POST http://localhost:8080/api/v1/objects/create) + OBJECT_COUNT=$(echo "$OBJECT_RESPONSE" | grep -o '[0-9]*$' || echo "0") + + if [ "$OBJECT_COUNT" -gt $OBJECT_THRESHOLD ]; then + echo "ALERT: Object count at $OBJECT_COUNT (threshold: $OBJECT_THRESHOLD)" + return 1 + fi + + return 0 +} + +# Run checks +echo "=== MEMORY ALERT CHECK ===" +ALERTS=0 + +if ! check_memory_usage; then + ALERTS=$((ALERTS + 1)) +fi + +if ! check_object_count; then + ALERTS=$((ALERTS + 1)) +fi + +if [ $ALERTS -eq 0 ]; then + echo "βœ… All memory metrics within normal ranges" +else + echo "⚠️ $ALERTS alert(s) triggered" +fi + +exit $ALERTS +EOF +chmod +x memory-alerts.sh + +# Test alerting +./memory-alerts.sh +``` + +--- + +## 🎯 Module 4 Assessment + +### Implementation Validation Checklist + +**βœ… Emergency Response Completed:** +- [ ] Successfully changed configuration to `coco=false` +- [ ] Verified `NoCocoController` is now active +- [ ] Confirmed bounds checking is working (MAX_OBJECTS limit) +- [ ] Validated thread pool management is operational +- [ ] Application remains stable and responsive + +**βœ… Code Pattern Understanding:** +- [ ] Identified bounded collection implementation +- [ ] Understood shared thread pool lifecycle management +- [ ] Recognized `@PreDestroy` cleanup pattern +- [ ] Analyzed thread safety improvements +- [ ] Documented key differences between implementations + +**βœ… Monitoring and Validation:** +- [ ] Generated post-fix profiling data +- [ ] Completed sustained load testing (10+ minutes) +- [ ] Implemented memory usage monitoring +- [ ] Created alerting thresholds and scripts +- [ ] Documented baseline metrics for comparison + +**βœ… Production Readiness:** +- [ ] Validated fixes under realistic load conditions +- [ ] Established ongoing monitoring capabilities +- [ ] Created alerting for early problem detection +- [ ] Documented implementation for team knowledge transfer + +### 🎯 Advanced Challenge: Custom Resource Management Pattern + +**Challenge:** Implement your own resource management pattern following the principles learned + +**Scenario:** Create a custom cache implementation that prevents memory leaks + +**Requirements:** +```java +// Implement this interface following NoCocoController patterns +public class SafeCache { + private static final int MAX_CACHE_SIZE = 1000; + private final Map cache = /* your implementation */; + + // TODO: Implement bounded put method + public V put(K key, V value) { + // Your bounds-checking implementation + } + + // TODO: Implement cleanup method + @PreDestroy + public void cleanup() { + // Your resource cleanup implementation + } +} +``` + +**Success Criteria:** +- [ ] Implements bounds checking to prevent unbounded growth +- [ ] Provides graceful handling when limits are reached +- [ ] Includes proper cleanup lifecycle management +- [ ] Thread-safe for concurrent access +- [ ] Includes monitoring/observability features + +--- + +## πŸš€ Transition to Module 5 + +**Fantastic implementation work!** You've successfully: +- βœ… Applied the immediate configuration fix to eliminate memory leaks +- βœ… Understood and analyzed the resource management patterns +- βœ… Validated fixes through comprehensive testing +- βœ… Implemented monitoring and alerting infrastructure +- βœ… Demonstrated production-ready resource lifecycle management + +### **What's Next?** +In **Module 5: Validation and Comparison**, we'll focus on: +- Using @164-java-profiling-compare to rigorously validate improvements +- Generating before/after profiling comparisons +- Creating quantitative evidence of memory leak resolution +- Documenting the complete success story with measurable results + +### πŸ’‘ Key Takeaway +**"The best fixes are not just functional - they're observable, maintainable, and educational. By understanding the patterns in NoCocoController, you've learned enterprise-grade resource management that applies far beyond this demo!"** + +**Ready to prove your fixes work with rigorous before/after analysis? [Let's complete the journey in Module 5!](module-5-validation.html) πŸ“Š** diff --git a/site-generator/content/courses/profile-memory-leak/module-5-validation.md b/site-generator/content/courses/profile-memory-leak/module-5-validation.md new file mode 100644 index 00000000..23d1d105 --- /dev/null +++ b/site-generator/content/courses/profile-memory-leak/module-5-validation.md @@ -0,0 +1,615 @@ +title=Module 5: Validation and Comparison +type=course +status=published +date=2025-09-17 +author=Juan Antonio BreΓ±a Moral +version=0.11.0-SNAPSHOT +tags=java, profiling, memory-leak, validation, comparison, before-after +~~~~~~ + +## Rigorous Before/After Analysis using @164-java-profiling-compare + +**⏱️ Duration:** 1 hour +**🎯 Learning Objectives:** +- Master the @164-java-profiling-compare system prompt for rigorous validation +- Generate comprehensive before/after profiling comparisons +- Create quantitative evidence of memory leak resolution +- Document measurable performance improvements +- Establish ongoing monitoring strategies for production deployment + +--- + +## 🎯 The Validation Framework + +### Understanding @164-java-profiling-compare Methodology + +The comparison system prompt provides a **rigorous framework** for validating performance improvements: + +``` +Baseline Data β†’ Implementation β†’ Post-Fix Data β†’ Comparative Analysis β†’ Quantified Results +``` + +**Key Principles:** +1. **Controlled Conditions**: Identical test scenarios for accurate comparison +2. **Quantitative Metrics**: Measurable improvements with specific numbers +3. **Visual Evidence**: Side-by-side flamegraph analysis +4. **Regression Detection**: Identify any unintended performance impacts +5. **Success Validation**: Confirm optimization goals were achieved + +### πŸ’‘ Learning Insight +**Effective performance validation requires the same rigor as scientific experiments - controlled conditions, reproducible results, and quantifiable outcomes. This module teaches you to think like a performance scientist!** + +--- + +## πŸ“Š Step 1: Baseline vs Post-Fix Data Collection + +### **🎯 Practical Exercise 1: Generating Post-Fix Profiling Data** + +Since you've implemented the fixes in Module 4, let's generate comprehensive post-fix data: + +```bash +cd ./cursor-rules-java/examples/spring-boot-memory-leak-demo + +# Verify we're running with fixes enabled +echo "=== VERIFYING FIX STATUS ===" +curl -s http://localhost:8080/actuator/env/coco | grep -E '"value"|"name"' + +# Ensure application is stable +sleep 10 +curl -s http://localhost:8080/actuator/health +``` + +#### **Generate Comprehensive Post-Fix Profiling Reports** +```bash +cd profiler/scripts + +echo "=== GENERATING POST-FIX PROFILING DATA ===" +echo "This will take approximately 6.5 minutes for complete analysis..." + +# Generate the complete memory analysis workflow (same as baseline) +./profile-java-process.sh +# Select: 9. Complete Memory Analysis Workflow + +# In another terminal, generate identical load pattern as baseline +cd ./cursor-rules-java/examples/spring-boot-memory-leak-demo + +# Create load script that matches baseline conditions +cat > post-fix-load.sh << 'EOF' +#!/bin/bash +echo "=== POST-FIX LOAD GENERATION ===" +echo "Phase 1: Baseline load (30s)" +timeout 30s bash -c 'while true; do curl -s -X POST http://localhost:8080/api/v1/objects/create > /dev/null; sleep 1; done' & + +echo "Phase 2: Detailed analysis load (60s)" +sleep 30 +timeout 60s bash -c 'while true; do curl -s -X POST http://localhost:8080/api/v1/objects/create > /dev/null; curl -s -X POST http://localhost:8080/api/v1/threads/create > /dev/null; sleep 0.5; done' & + +echo "Phase 3: Leak detection load (5min)" +sleep 90 +timeout 300s bash -c 'while true; do curl -s -X POST http://localhost:8080/api/v1/objects/create > /dev/null; sleep 0.3; done' & + +wait +echo "All post-fix load phases completed" +EOF +chmod +x post-fix-load.sh + +# Execute the load generation +./post-fix-load.sh +``` + +#### **Organize Results for Comparison** +```bash +# Create comparison workspace +mkdir -p profiler/comparison-analysis +cd profiler/comparison-analysis + +# Organize baseline reports (from Module 2) +echo "=== ORGANIZING BASELINE REPORTS ===" +mkdir -p baseline post-fix + +# Copy baseline reports (look for older timestamps) +cp ../results/memory-baseline-*.html baseline/ 2>/dev/null || echo "No baseline reports found" +cp ../results/memory-leak-*.html baseline/ 2>/dev/null || echo "No leak detection reports found" +cp ../results/allocation-flamegraph-*.html baseline/ 2>/dev/null || echo "No allocation reports found" + +# Copy post-fix reports (look for recent timestamps) +RECENT_DATE=$(date +%Y%m%d) +cp ../results/memory-baseline-${RECENT_DATE}*.html post-fix/ 2>/dev/null || echo "No recent baseline reports found" +cp ../results/memory-leak-*${RECENT_DATE}*.html post-fix/ 2>/dev/null || echo "No recent leak detection reports found" + +# Create inventory +echo "=== COMPARISON INVENTORY ===" +echo "Baseline reports: $(ls baseline/ 2>/dev/null | wc -l)" +echo "Post-fix reports: $(ls post-fix/ 2>/dev/null | wc -l)" + +ls -la baseline/ post-fix/ +``` + +--- + +## πŸ” Step 2: Side-by-Side Flamegraph Analysis + +### **🎯 Practical Exercise 2: Visual Comparison Analysis** + +#### **Open Reports for Side-by-Side Comparison** +```bash +# Find the most relevant comparison files +BASELINE_LEAK=$(ls baseline/memory-leak-*.html 2>/dev/null | head -1) +POSTFIX_LEAK=$(ls post-fix/memory-leak-*.html 2>/dev/null | head -1) + +if [ -n "$BASELINE_LEAK" ] && [ -n "$POSTFIX_LEAK" ]; then + echo "Opening flamegraphs for comparison:" + echo "Baseline: $BASELINE_LEAK" + echo "Post-fix: $POSTFIX_LEAK" + + # macOS + if [[ "$OSTYPE" == "darwin"* ]]; then + open "$BASELINE_LEAK" + sleep 2 + open "$POSTFIX_LEAK" + # Linux + else + xdg-open "$BASELINE_LEAK" & + sleep 2 + xdg-open "$POSTFIX_LEAK" & + fi +else + echo "Missing comparison files. Ensure you have both baseline and post-fix reports." +fi +``` + +#### **Systematic Visual Analysis Framework** +```bash +# Create visual comparison template +cat > visual-comparison-analysis.md << 'EOF' +# Visual Flamegraph Comparison Analysis + +## Report Information +- **Baseline Report**: [filename] +- **Post-Fix Report**: [filename] +- **Analysis Date**: [date] +- **Load Conditions**: [identical/different - describe] + +## Visual Comparison Metrics + +### Canvas Characteristics +| Metric | Baseline | Post-Fix | Change | Improvement | +|--------|----------|----------|--------|-------------| +| Canvas Height (px) | [measure] | [measure] | [calculate] | [better/worse/same] | +| Canvas Width (px) | [measure] | [measure] | [calculate] | [better/worse/same] | +| Visual Complexity | [high/med/low] | [high/med/low] | [describe] | [better/worse/same] | + +### Stack Depth Analysis +| Metric | Baseline | Post-Fix | Change | Improvement | +|--------|----------|----------|--------|-------------| +| Maximum Stack Depth | [count] | [count] | [calculate] | [better/worse/same] | +| Average Stack Depth | [estimate] | [estimate] | [calculate] | [better/worse/same] | +| Complex Stack Patterns | [count] | [count] | [calculate] | [better/worse/same] | + +### Method-Level Patterns +| Method/Pattern | Baseline Width | Post-Fix Width | Change | Notes | +|----------------|----------------|----------------|--------|-------| +| CocoController.createObject | [wide/narrow/absent] | [wide/narrow/absent] | [describe] | [should be absent in post-fix] | +| NoCocoController.createObject | [absent] | [wide/narrow/absent] | [describe] | [should be present in post-fix] | +| ArrayList.add (unbounded) | [wide/narrow/absent] | [wide/narrow/absent] | [describe] | [should be reduced/absent] | +| Bounds checking logic | [absent] | [narrow/wide/absent] | [describe] | [should be present in post-fix] | + +## Key Visual Differences +### Memory Leak Indicators (Should be RESOLVED) +- [ ] Continuous allocation patterns: [resolved/still present] +- [ ] Growing stack complexity: [resolved/still present] +- [ ] Unbounded collection growth: [resolved/still present] +- [ ] Thread pool creation patterns: [resolved/still present] + +### Positive Changes (Should be PRESENT) +- [ ] Bounds checking logic visible: [present/absent] +- [ ] Shared resource patterns: [present/absent] +- [ ] Cleanup/lifecycle patterns: [present/absent] +- [ ] Error handling paths: [present/absent] + +## Overall Assessment +- **Memory Leak Resolution**: [Complete/Partial/Failed] +- **Performance Impact**: [Improved/Neutral/Degraded] +- **Pattern Quality**: [Better/Same/Worse] +- **Confidence Level**: [High/Medium/Low] + +## Recommendations +1. [Next action item 1] +2. [Next action item 2] +3. [Next action item 3] +EOF + +echo "Visual comparison template created. Fill in with your observations." +``` + +--- + +## πŸ“ˆ Step 3: Quantitative Metrics Extraction + +### **🎯 Practical Exercise 3: Measurable Improvement Analysis** + +#### **Extract Quantitative Data from Reports** +```bash +# Create measurement extraction script +cat > extract-metrics.sh << 'EOF' +#!/bin/bash +echo "=== QUANTITATIVE METRICS EXTRACTION ===" + +extract_metrics() { + local file="$1" + local label="$2" + + if [ ! -f "$file" ]; then + echo "$label: File not found" + return + fi + + echo "=== $label ===" + echo "File: $(basename "$file")" + echo "Size: $(wc -c < "$file") bytes" + echo "Generated: $(stat -c %y "$file" 2>/dev/null || stat -f %Sm "$file")" + + # Extract technical metrics from HTML + local height=$(grep -o 'height="[0-9]*"' "$file" | head -1 | grep -o '[0-9]*') + local width=$(grep -o 'width="[0-9]*"' "$file" | head -1 | grep -o '[0-9]*') + local frames=$(grep -c 'class="func_g"' "$file") + local texts=$(grep -c ' metrics-comparison.txt +cat metrics-comparison.txt +``` + +#### **Calculate Improvement Percentages** +```bash +# Create improvement calculation script +cat > calculate-improvements.sh << 'EOF' +#!/bin/bash +echo "=== IMPROVEMENT CALCULATIONS ===" + +# Function to calculate percentage change +calc_improvement() { + local baseline="$1" + local postfix="$2" + local metric_name="$3" + + if [ -z "$baseline" ] || [ -z "$postfix" ] || [ "$baseline" -eq 0 ]; then + echo "$metric_name: Cannot calculate (missing data)" + return + fi + + local change=$((postfix - baseline)) + local percent=$((change * 100 / baseline)) + + if [ $change -lt 0 ]; then + echo "$metric_name: IMPROVED by ${percent#-}% (${baseline} β†’ ${postfix})" + elif [ $change -gt 0 ]; then + echo "$metric_name: INCREASED by ${percent}% (${baseline} β†’ ${postfix})" + else + echo "$metric_name: NO CHANGE (${baseline})" + fi +} + +# Example calculations (you'll need to fill in actual values) +echo "Fill in the actual values from your metrics-comparison.txt:" +echo "" +echo "# Example calculations:" +echo "# calc_improvement 800 400 'Canvas Height'" +echo "# calc_improvement 1200 600 'Stack Frames'" +echo "# calc_improvement 50000 25000 'File Size'" + +# Template for your calculations +cat << 'TEMPLATE' +# Replace these example values with your actual measurements: + +# Canvas Height comparison +# calc_improvement [baseline_height] [postfix_height] "Canvas Height" + +# Stack Frames comparison +# calc_improvement [baseline_frames] [postfix_frames] "Stack Frames" + +# File Size comparison +# calc_improvement [baseline_size] [postfix_size] "File Size" + +TEMPLATE +EOF +chmod +x calculate-improvements.sh + +./calculate-improvements.sh +``` + +--- + +## πŸ“‹ Step 4: Creating Comparison Documentation + +### **Following @164-java-profiling-compare Template** + +```bash +# Create comprehensive comparison analysis document +DATE_SUFFIX=$(date +%Y%m%d) +cat > profiling-comparison-analysis-${DATE_SUFFIX}.md << 'EOF' +# Profiling Comparison Analysis - [DATE] + +## Executive Summary +- **Refactoring Objective**: Eliminate memory leaks in Spring Boot demo application +- **Overall Result**: [SUCCESS/PARTIAL/FAILED] +- **Key Improvements**: + - Memory leak patterns eliminated + - Resource lifecycle management implemented + - Application stability under load confirmed + - [Add specific improvements based on your analysis] + +## Methodology +- **Baseline Date**: [Date of original profiling from Module 2] +- **Post-Refactoring Date**: [Today's date] +- **Test Scenarios**: Identical load patterns using coordinated JMeter testing +- **Duration**: Complete Memory Analysis Workflow (6.5 minutes total) +- **Load Pattern**: 30s baseline + 60s detailed + 300s leak detection + +## Before/After Metrics +| Metric | Before (Baseline) | After (Post-Fix) | Improvement | +|--------|-------------------|------------------|-------------| +| Canvas Height (pixels) | [your measurement] | [your measurement] | [calculate %] | +| Stack Frames (count) | [your measurement] | [your measurement] | [calculate %] | +| File Size (bytes) | [your measurement] | [your measurement] | [calculate %] | +| Visual Complexity | [HIGH/MED/LOW] | [HIGH/MED/LOW] | [better/worse/same] | +| Memory Growth Pattern | Continuous growth | Bounded/stable | βœ… RESOLVED | +| Thread Pool Behavior | New pools per request | Shared managed pool | βœ… RESOLVED | + +## Key Findings + +### βœ… Resolved Issues +- [x] **Unbounded Collection Growth**: ArrayList.add patterns eliminated from flamegraphs +- [x] **Thread Pool Leaks**: ExecutorService creation patterns no longer visible +- [x] **Memory Accumulation**: Long-term allocation patterns stabilized +- [x] **Resource Cleanup**: @PreDestroy patterns now visible in profiling data + +### πŸ” Performance Characteristics +- [x] **Bounds Checking**: New error handling paths visible in post-fix flamegraphs +- [x] **Shared Resources**: Thread pool management patterns consolidated +- [x] **Lifecycle Management**: Cleanup and shutdown patterns implemented +- [x] **Error Handling**: Graceful degradation under load limits + +### πŸ“Š Quantitative Improvements +- **Memory Leak Elimination**: [X]% reduction in continuous allocation patterns +- **Stack Complexity**: [X]% reduction in average stack depth +- **Resource Efficiency**: [X]% improvement in thread management patterns +- **Stability**: Application maintains consistent performance under sustained load + +## Visual Evidence +- **Baseline Reports**: `baseline/memory-leak-*.html` +- **After Reports**: `post-fix/memory-leak-*.html` +- **Key Differences**: + - CocoController allocation patterns absent in post-fix reports + - NoCocoController bounds checking visible in post-fix reports + - Thread pool creation patterns eliminated + - Error handling paths clearly visible + +## Load Testing Validation +- **Sustained Load Test**: 10+ minutes at 3 concurrent users +- **Memory Stability**: No continuous growth patterns observed +- **Response Time**: Maintained under 100ms for all endpoints +- **Error Handling**: Graceful degradation when limits reached +- **Resource Usage**: CPU and memory usage remained stable + +## Production Readiness Assessment +- [x] **Performance targets met**: Memory leaks eliminated +- [x] **No regressions introduced**: Application functionality maintained +- [x] **Load testing completed**: Sustained load validation successful +- [x] **Monitoring configured**: Memory alerts and thresholds established + +## Recommendations +1. **Deploy to Production**: Fixes validated and ready for production deployment +2. **Enable Monitoring**: Activate memory usage alerts and dashboards +3. **Update Documentation**: Share learnings with development team +4. **Continuous Monitoring**: Implement ongoing profiling in CI/CD pipeline + +## Success Validation +- **Technical Success**: βœ… All memory leak patterns eliminated +- **Performance Success**: βœ… Application stability maintained under load +- **Monitoring Success**: βœ… Alerting and monitoring infrastructure operational +- **Knowledge Transfer**: βœ… Team equipped with profiling and analysis skills + +## Risk Assessment +- **Deployment Risk**: LOW - Configuration change with proven results +- **Performance Risk**: LOW - No performance degradation observed +- **Regression Risk**: LOW - Comprehensive testing completed +- **Operational Risk**: LOW - Monitoring and alerting in place +EOF + +echo "Comparison analysis document created: profiling-comparison-analysis-${DATE_SUFFIX}.md" +echo "Please fill in the specific measurements from your analysis." +``` + +### **Create Final Results Summary** +```bash +# Create final results summary +cat > profiling-final-results-${DATE_SUFFIX}.md << 'EOF' +# Profiling Final Results - [DATE] + +## Summary +- **Analysis Date**: [Today's date] +- **Performance Objective**: Eliminate memory leaks in Spring Boot demo application +- **Status**: βœ… COMPLETE - All objectives achieved +- **Implementation**: coco=false configuration successfully deployed + +## Key Metrics Summary +| Performance Area | Before | After | Improvement | +|---|---|----|----| +| Memory Leaks | Active leaks detected | No leaks detected | βœ… 100% resolved | +| Memory Growth | Continuous unbounded | Stable bounded | βœ… Stabilized | +| Thread Management | New pools per request | Shared managed pool | βœ… 90%+ efficiency | +| Resource Cleanup | No cleanup logic | @PreDestroy implemented | βœ… Complete lifecycle | +| Error Handling | No bounds checking | Graceful degradation | βœ… Production ready | + +## Critical Issues Resolved +1. **Unbounded Collection Growth**: Implemented MAX_OBJECTS bounds with graceful error handling +2. **Thread Pool Resource Leaks**: Replaced per-request pools with shared managed ExecutorService +3. **Missing Resource Cleanup**: Added @PreDestroy lifecycle management with proper shutdown +4. **Lack of Monitoring**: Established memory usage monitoring and alerting infrastructure + +## Technical Achievements +- **Configuration Management**: Demonstrated feature flag pattern (coco=true/false) +- **Resource Lifecycle**: Implemented enterprise-grade resource management patterns +- **Performance Validation**: Rigorous before/after comparison with quantitative evidence +- **Monitoring Infrastructure**: Comprehensive memory monitoring and alerting system +- **Knowledge Transfer**: Complete documentation and team education + +## Production Readiness +- [x] **Performance targets met**: All memory leak patterns eliminated +- [x] **No regressions introduced**: Application functionality fully maintained +- [x] **Load testing completed**: Sustained load validation over 10+ minutes +- [x] **Monitoring alerts configured**: Memory usage thresholds and alerting operational +- [x] **Documentation complete**: Full analysis and implementation documentation +- [x] **Team knowledge transfer**: Profiling skills and patterns shared + +## Business Impact +- **Risk Mitigation**: Eliminated potential production outages from memory exhaustion +- **Performance**: Improved application stability and resource efficiency +- **Cost**: Minimal development investment with maximum impact +- **Timeline**: Issue identified, analyzed, and resolved within course duration +- **Knowledge**: Team equipped with systematic performance analysis skills + +## Lessons Learned +- **Systematic Approach**: Structured profiling methodology produces reliable results +- **Evidence-Based**: Quantitative analysis enables confident decision-making +- **Pattern Recognition**: Understanding resource lifecycle patterns prevents similar issues +- **Monitoring Importance**: Proactive monitoring prevents problems before they impact users +- **Documentation Value**: Thorough documentation enables knowledge sharing and future reference + +## Next Steps +1. **Production Deployment**: Deploy coco=false configuration to production environment +2. **Monitoring Activation**: Enable memory usage alerts and dashboards in production +3. **Process Integration**: Add profiling validation to CI/CD pipeline +4. **Team Training**: Share profiling techniques and patterns with broader development team +5. **Continuous Improvement**: Establish regular performance review and optimization cycles + +## Related Documents +- **Analysis**: `profiling-comparison-analysis-[DATE].md` +- **Baseline Reports**: `baseline/*.html` +- **Post-Fix Reports**: `post-fix/*.html` +- **Monitoring Scripts**: `monitor-memory.sh`, `memory-alerts.sh` + +--- + +**πŸŽ‰ COURSE COMPLETION: Congratulations on mastering Java memory leak detection and resolution using systematic profiling techniques and system prompts!** +EOF + +echo "Final results summary created: profiling-final-results-${DATE_SUFFIX}.md" +``` + +--- + +## 🎯 Module 5 Assessment and Course Completion + +### Final Validation Checklist + +**βœ… Comparative Analysis Mastery:** +- [ ] Generated post-fix profiling data under identical conditions +- [ ] Performed side-by-side flamegraph comparison +- [ ] Extracted quantitative metrics from before/after reports +- [ ] Calculated improvement percentages and impact measurements +- [ ] Created comprehensive comparison documentation + +**βœ… Evidence-Based Validation:** +- [ ] Documented visual evidence of memory leak resolution +- [ ] Quantified performance improvements with specific metrics +- [ ] Validated fixes through sustained load testing +- [ ] Confirmed no performance regressions introduced +- [ ] Established ongoing monitoring and alerting + +**βœ… Professional Documentation:** +- [ ] Created comparison analysis following @164-java-profiling-compare template +- [ ] Generated final results summary suitable for stakeholders +- [ ] Documented lessons learned and best practices +- [ ] Provided actionable recommendations for production deployment +- [ ] Established foundation for future performance optimization work + +### πŸ† Course Completion Achievement + +**Congratulations!** You have successfully completed the **"Java Memory Leak Detection Course - From Detection to Resolution using System Prompts"** + +**Your Achievements:** +- βœ… **Module 1**: Mastered memory leak foundations and detection setup +- βœ… **Module 2**: Became proficient with 21 profiling options and flamegraph interpretation +- βœ… **Module 3**: Applied systematic analysis and created evidence-based documentation +- βœ… **Module 4**: Implemented enterprise-grade resource management patterns +- βœ… **Module 5**: Validated improvements through rigorous comparative analysis + +### πŸŽ“ Skills Acquired + +**Technical Proficiency:** +- async-profiler mastery with 21+ profiling options +- JFR analysis and interpretation +- Flamegraph visual analysis and pattern recognition +- JMeter load testing integration +- Memory monitoring and alerting setup + +**Analytical Skills:** +- Systematic problem identification and categorization +- Impact/Effort prioritization frameworks +- Cross-correlation analysis techniques +- Evidence-based documentation +- Quantitative improvement measurement + +**Professional Competencies:** +- Enterprise resource lifecycle management patterns +- Production-ready monitoring and alerting +- Stakeholder communication and reporting +- Knowledge transfer and team education +- Continuous improvement methodologies + +--- + +## πŸ’‘ Final Reflection + +### **Key Takeaways** +- **Systematic Methodology**: Structured approaches produce reliable, reproducible results +- **Evidence-Based Decisions**: Quantitative analysis enables confident optimization choices +- **Pattern Recognition**: Understanding resource lifecycle patterns prevents entire classes of issues +- **Continuous Learning**: Performance optimization is an ongoing discipline requiring constant skill development + +### **The Power of System Prompts** +Through this course, you've experienced how system prompts (@161, @162, @164) provide: +- **Structured Workflows**: Consistent, repeatable processes +- **Best Practices**: Proven methodologies +- **Knowledge Transfer**: Systematic approaches that can be taught and shared +- **Quality Assurance**: Built-in validation and verification steps + +**πŸŽ‰ You've not just learned to fix memory leaks - you've mastered a systematic approach to performance optimization that will serve you throughout your career!** + +**Thank you for completing this comprehensive course. Your dedication to learning systematic performance optimization techniques will make you a more effective developer and a valuable team member. Keep profiling, keep learning, and keep optimizing! [Return to the beginning](index.html) πŸš€** diff --git a/site-generator/templates/maincss.ftl b/site-generator/templates/maincss.ftl index f811f1a6..bc5a5f5f 100644 --- a/site-generator/templates/maincss.ftl +++ b/site-generator/templates/maincss.ftl @@ -241,6 +241,9 @@ img { } .navbar-custom .nav .navlinks-children { position: absolute; + min-width: 200px; + width: max-content; + white-space: nowrap; } .navbar-custom .nav .navlinks-container .navlinks-children a { padding-left: 10px; diff --git a/site-generator/templates/nav.ftl b/site-generator/templates/nav.ftl index 672307ee..335c7bb9 100644 --- a/site-generator/templates/nav.ftl +++ b/site-generator/templates/nav.ftl @@ -23,6 +23,7 @@ height="0" width="0" style="display:none;visibility:hidden"> Courses
    Java Generics + Memory Leak Profiling
  • Archive