This is an issue when compilation or preparation methods are called inside loop bodies with constant or loop-invariant arguments. This includes pattern compilation methods for regular expressions, string methods that accept regular expression patterns (such as match, replace, and split operations), and database statement preparation methods.

In Java, this specifically refers to Pattern.compile(), String regex methods (matches(), replaceAll(), replaceFirst(), split()), and Connection.prepareStatement().

Why is this an issue?

Compilation and preparation operations are expensive because they involve parsing, validation, and internal representation building. When these operations are performed inside loops with constant or loop-invariant arguments, the same work is repeated unnecessarily on every iteration.

Regular expression compilation

When you call functions that compile regular expressions from strings or use string methods that accept regex patterns, the language runtime must:

• Parse the regular expression syntax
• Validate the pattern
• Build an internal finite automaton (state machine)
• Allocate memory for the compiled pattern

These steps happen every time, even when the pattern string is identical. For example, calling a string matching method with a pattern like "\d+" inside a loop that processes 1,000 items means compiling the same pattern 1,000 times.

Database prepared statement preparation

When you call methods that create prepared statements from SQL strings, the database driver must:

• Send the SQL string to the database server
• Parse and validate the SQL syntax
• Create an execution plan
• Allocate server-side resources (cursors, statement handles)
• Return a client-side prepared statement object

Prepared statements exist specifically to avoid this overhead by allowing you to compile once and execute many times with different parameters. Calling statement preparation methods inside a loop with the same SQL string defeats this purpose entirely.

The performance cost

The repeated compilation/preparation causes:

• CPU waste: Parsing and compilation happen repeatedly instead of once
• Memory churn: Temporary objects are created and discarded on each iteration
• Network overhead: For database operations, each preparation call may involve network round-trips
• Slower execution: A loop that should take milliseconds might take seconds when processing large datasets

What is the potential impact?

The application may experience:

• Degraded performance: Operations that should be fast become noticeably slow, especially when processing large collections or datasets
• Resource exhaustion: For database operations, repeatedly creating parameterized query objects can exhaust server-side cursor or statement handle limits, causing connection failures
• Poor scalability: The performance penalty multiplies as data volume increases, making the application unable to handle production workloads efficiently
• Increased costs: Higher CPU usage and longer execution times can lead to increased infrastructure costs in cloud environments

Exceptions

String.split() does not compile a regular expression when the argument meets either of these conditions:

• It is a one-char String and this character is not one of the regex metacharacters ".$|()[{^?*+\"
• It is a two-char String and the first char is the backslash and the second is not an ASCII digit or letter.

In these cases, no issue is raised.

How to fix it

For regular expression operations, compile the Pattern once before the loop and reuse it inside the loop. Do not move String.matches(), replaceAll(), replaceFirst(), or split() outside the loop: the receiver still changes on each iteration. Replace those calls with Pattern.matcher() or Pattern.split() applied to each input.

For database operations, prepare the statement once before the loop and reuse it with different parameters.

Code examples

Noncompliant code example

for (String input : inputs) {
    Pattern p = Pattern.compile("[a-z]+");  // Noncompliant
    Matcher m = p.matcher(input);
    if (m.find()) {
        handle(m.group());
    }
}

Compliant solution

Pattern LOWER = Pattern.compile("[a-z]+");
for (String input : inputs) {
    Matcher m = LOWER.matcher(input);
    if (m.find()) {
        handle(m.group());
    }
}

Noncompliant code example

for (String input : inputs) {
    if (input.matches("[a-z]+")) {  // Noncompliant
        handle(input);
    }
}

Compliant solution

Pattern LOWER = Pattern.compile("[a-z]+");
for (String input : inputs) {
    if (LOWER.matcher(input).matches()) {
        handle(input);
    }
}

Noncompliant code example

for (int id : ids) {
    PreparedStatement ps = connection.prepareStatement("SELECT * FROM t WHERE id = ?");  // Noncompliant
    ps.setInt(1, id);
    ps.execute();
    ps.close();
}

Compliant solution

PreparedStatement ps = connection.prepareStatement("SELECT * FROM t WHERE id = ?");
for (int id : ids) {
    ps.setInt(1, id);
    ps.execute();
}

Resources

Documentation

• Java Documentation - Pattern (Java SE 17 & JDK 17)
• Java Documentation - PreparedStatement (Java SE 17 & JDK 17)

Articles & blog posts

• Baeldung - Guide to Java Regular Expressions API

Related rules

• {rule:java:S4248} - Regex patterns should not be created needlessly
• {rule:java:S6909} - Constant parameters in a "PreparedStatement" should not be set more than once