Static analysis limits regarding runtime connection pool exhaustion

Qodana utilizes data-flow analysis to identify potential resource leaks, such as unclosed JDBC connections or file streams. While the tool is effective at flagging structural issues where a resource is instantiated but not explicitly closed, its visibility is limited to the source code state.

Intermittent connection pool exhaustion often stems from runtime factors like traffic spikes, concurrency bottlenecks, or environment-specific configurations that are not reflected in the static codebase. Because Qodana operates within CI/CD pipelines without access to live metrics, it cannot observe the actual state of a database connection pool under load.

Are there specific inspection profiles or custom detektor configurations designed to identify architectural anti-patterns likely to lead to exhaustion? Can Qodana distinguish between a genuine resource leak and a connection managed by an external dependency injection framework?