We discovered a significant performance bottleneck in our Java application using the Akka framework, which was attributed to an irregular flow of incoming tasks and high maximum number of threads in the underlying thread pool. This led to frequent spikes in CPU usage due to expensive native calls made by the `ForkJoinPool.scan()` and `Unsafe.park()` methods. By analyzing flame graphs and profiling output, we identified the root cause as the default Akka dispatcher using a `ForkJoinPool` with 32 threads, which was not stable under our workload. We fixed the issue by moving the problematic actor to a more suitable "work" dispatcher with a stable flow of tasks, resulting in a 30% reduction in overall CPU usage and confirming our hypothesis through configuration changes.