perf：Optimize Spring Boot startup time and runtime performance

[dennis9486]

Title

Optimize Spring Boot startup time and runtime performance

Summary

Current services have slow startup and elevated request latency in production. The goal is to systematically optimize Spring Boot application startup time and overall runtime performance (both startup and steady-state), while keeping functionality unchanged — enabling faster iteration and improving production stability.

Goals

• Significantly reduce startup time (target: cold start ↓ ≥30% or meet team KPI).
• Use CPU/memory more efficiently; minimize unnecessary initialization and memory footprint.
• Reduce latency for critical requests and improve or stabilize throughput.
• Improve observability (startup time monitoring, slow-start alerts, performance metrics).

Task checklist

• [ ] Collect baseline metrics: cold/hot startup time, memory usage, major API P95/P99 latency, GC/CPU usage.
• [ ] Startup optimizations
  • [ ] Enable Spring Boot lazy-initialization (gradually and per scenario).
  • [ ] Remove or defer initialization of unnecessary @Component/@Configuration (use @Conditional / @Lazy).
  • [ ] Trim auto-configuration (exclude unused starters or use spring.autoconfigure.exclude).
  • [ ] Move heavy or non-essential bean initialization to async background tasks (execute after ApplicationReadyEvent).
  • [ ] Enable class data sharing / tune JVM options (CDS/AppCDS, tune G1/ZGC as appropriate).
• [ ] Dependency & build optimizations
  • [ ] Audit and remove redundant dependencies to reduce class-loading time.
  • [ ] Use Spring Boot starters judiciously to keep dependency surface minimal.
  • [ ] Evaluate build-time optimizations: --release, AOT, or GraalVM Native Image (cost/benefit analysis required).
• [ ] Runtime performance
  • [ ] Profile slow methods and hotspots (async-profiler / JFR / YourKit).
  • [ ] Optimize hotspots (caching, batching, reduce locks, add DB indexes).
  • [ ] Optimize DB interactions (SQL tuning, connection pool tuning, batching/pagination, fix N+1).
  • [ ] Introduce/optimize caching (local/distributed) and prevent cache penetration/storms.
• [ ] Middleware & configuration
  • [ ] Tune MQ/thread-pool/connection-pool settings (reasonable core/max, queue length, rejection policy).
  • [ ] Ensure proper metrics (Prometheus) and tracing (OpenTelemetry/Zipkin) are configured.
• [ ] Testing & validation
  • [ ] Regression tests to ensure functionality remains unchanged.
  • [ ] Performance tests: compare startup baselines, load tests (QPS/concurrency/latency), memory/GC monitoring.
  • [ ] Canary rollouts with monitoring before full release.

Acceptance criteria

• Cold start average time reduced ≥30% vs baseline or reaches agreed team target.
• Key API P95 latency reduced and maintained within SLA.
• Average memory usage reduced or GC pause time significantly improved.
• Production monitoring dashboard includes startup time, slow requests, GC/CPU/memory, thread-pool saturation.
• Changes pass unit/integration/performance tests and show no anomalies during canary.

Notes & recommendations

• Prioritize reversible, low-risk optimizations first (lazy init, dependency pruning, deferred init). High-risk approaches (GraalVM AOT, major architecture changes) need careful cost/compatibility assessment.
• Watch for heavy third-party initialization (drivers, SDKs); load such components lazily or asynchronously if they are costly.
• Keep rollback plans and robust monitoring; observe metrics for 24–72 hours after deployment.
• Repeat baseline tests regularly (add startup time checks into CI) to prevent regressions.

References (optional)

• Spring Boot official performance tuning guides
• JDK Flight Recorder / async-profiler for performance analysis
• GraalVM & Spring Native evaluation materials

[jxfzzzt]

首先对项目的子模块进行统一版本管理 https://github.com/LucklySpace/Lucky-cloud/pull/18