Java 25’s new CPU-time profiler finally lands in JFR, and it’s exactly the kind of pragmatic improvement that keeps Java vibrant. Execution-time sampling hides where cycles burn; CPU-time sampling fixes that, thread-by-thread, with Linux’s per-CPU timer and new jdk.CPUTimeSample events. The result: flame graphs that show the real hotspots (think tenFastRequests) and report missed samples, without unsafe hacks. Yes, it’s Linux-only today—so profile on a prod-like box, not your Mac—but that’s how small teams ship: measure where it matters, then optimize. Tip: enable CPU-time alongside execution-time, and use the throttle setting to cap events by rate, not just an interval. Fewer meetings, more data: make throughput the metric, and let JFR guide the cuts.