Regular Expressions

A leading (?i) turns a flag on for the rest of the pattern. The form (?i:...) is a non-capturing group that applies the flag only inside that group. You turn a flag off for a region with (?-i:...).

A backreference like \1 matches the same text that an earlier capturing group already matched (not the pattern again, the actual text). A common use is finding doubled words, e.g. \b(\w+)\s+\1\b matches 'the the'.

Java's lookbehind must match text of a limited, known maximum length. So (?<=ab) is fine and bounded quantifiers like (?<=a{1,5}) work, but truly unbounded ones like (?<=a+) or (?<=a*) are not allowed because the engine must know how far back to look.

Match the empty positions between digits where exactly a multiple of three digits remain, using (?<=\d)(?=(\d{3})+$), and replace each with a comma. It matches zero-width positions, so no digit is consumed or removed - commas are just inserted.

Java's regex engine is a backtracking NFA, not a DFA. On certain patterns with nested or overlapping repetition it can try an exponential number of paths on a non-matching input, freezing the thread. This is catastrophic backtracking, the cause of regex denial-of-service (ReDoS).

A possessive quantifier (written with a trailing +, like a++) grabs as much as it can and then never gives any of it back — it disables backtracking for that part. An atomic group (?>...) does the same thing for a whole subpattern.

Possessive quantifiers (a++, a*+) and atomic groups ((?>...)) tell the engine: match as much as you can and never give any of it back. Removing those give-back choice points stops the exponential re-trying that causes the blowup.

String.replaceAll recompiles the regex on every call. In hot paths, compile the pattern once with Pattern.compile and reuse a Matcher (matcher.replaceAll). For replacements computed from each match, use appendReplacement/appendTail or replaceAll with a Function.

Java's regex engine backtracks. Ambiguous nested quantifiers and backreferences can make it try exponentially many combinations on certain inputs, freezing a thread (a denial of service). Avoid it with unambiguous patterns, atomic groups, possessive quantifiers, and input limits.

Catastrophic backtracking happens when nested or overlapping quantifiers give the engine exponentially many ways to match, so a crafted input makes one regex run effectively forever. An attacker can use this to freeze a thread — that's ReDoS. You prevent it with possessive quantifiers, atomic groups, or unambiguous patterns.

Find risky patterns with linters and code review, test patterns against malicious inputs, never let users supply patterns to the default engine, and run untrusted matching with a timeout or a linear-time engine like RE2J so no single regex can hang a thread.

split breaks on the matched delimiter and throws it away. If you split on a zero-width lookaround position instead, no characters are consumed, so the delimiter stays attached to a piece. For example split on (?<=,) keeps the comma at the end of each chunk.

region() limits matching to a sub-range of the input so methods like find() and matches() only see that window. reset() clears match state and position so you can search again or swap in new input. Reusing one Matcher avoids creating new objects when scanning sequentially.

Anchors like ^, $, and \b are built-in zero-width assertions that test a fixed position. Lookahead (?=...) and lookbehind (?<=...) are general zero-width assertions you define yourself, letting you build custom 'boundaries' that the standard anchors can't express.