Как сопоставить регулярное выражение без создания объектов в Java?

Question

Я работаю над функцией соответствия выражений reg. Проблема в том, что эта функция будет вызываться фреймворком внутри вложенного цикла. Если временные объекты создаются, GC вызовет очень большую проблему с производительностью.

Можно ли иметь дело с регулярными выражениями без создания временных объектов (Pattern, Matcher)? Переписать классы регулярных выражений - мой последний выбор ...

Answer 1

Matcher объекты не являются потокобезопасными, поэтому вы не можете использовать их повторно, если не вызовете метод reset() (который в одном потоке должен работать нормально) - см. Безопасен ли поток Java Regex?

Answer 2

Процитирую старую поговорку:

Заставь это работать, сделай это правильно, сделай это быстро. (в таком порядке)

Поэтому, прежде чем переходить к каким-либо тяжелым шагам по оптомизации, просто напишите исходный простой соответствующий код (который в этом случае может потребовать предварительной компиляции ваших шаблонов, если вы можете). Запустите несколько тестов и посмотрите, не является ли производительность недостаточной, а затем оптимизируйте, если часть регулярного выражения является узким местом.

Если создание объекта (и очистка) является серьезным узким местом (по сравнению с самим анализом регулярных выражений), то вам может потребоваться реализовать собственное решение, использующее пул объектов (чтобы объекты не создавались, просто сбросьте и повторно из бассейна). Я сомневаюсь, что это приведет к какому-либо серьезному повышению производительности, поэтому вам следует сначала провести сравнительный анализ, чтобы увидеть, насколько это возможно (даже если вы улучшите производительность создания / очистки объектов на 50%, будет ли это того стоить?).

Answer 3

Лучше всего вам решать проблемы по мере их возникновения, чего, вероятно, и не будет. Проблемы с производительностью вокруг большого количества маленьких живых объектов были проблемой около десяти лет назад, но теперь это невероятно хорошо.

Если вам нужно оптимизировать, то это должно быть в форме изменения параметров GC - например, размера молодого поколения, а не попытки оптимизации в коде.

Answer 4

как я вижу, у вас есть 2 жизнеспособных варианта:

1. Напишите свою собственную логику для сопоставления регулярных выражений, посмотрев на исходный код: Pattern и Matcher .
2. явно инициировать коллекцию этих объектов, когда вы закончите с ними, запустив соответствующую функцию finalize() вместо ожидания запуска ГХ.

Плюсы и минусы

1. Большая работа, которую необходимо проверить и поддерживать в будущем, однако вы получите полный контроль над тем, что вы пытаетесь сделать.

2. Не рекомендуется вмешиваться в работу ГХ, чистого раствора и простого раствора

Answer 5

Похоже, вы проводите раннюю оптимизацию, которая в вашем случае, скорее всего, будет бесполезной.Как насчет того, чтобы провести несколько тестов и решить?

Ура, Юджин

Answer 6

Вы можете предварительно скомпилировать свои регулярные выражения, что имеет смысл, если вы повторно используете одно и то же регулярное выражение несколько раз.

Вместо

boolean foundMatch = subjectString.matches("a.*b");

(где в любом случае будет создан временный скомпилированный Pattern), вы можете использовать

Pattern regex = Pattern.compile("a.*b");
// loop here
// do something...
    Matcher regexMatcher = regex.matcher(subjectString);
    boolean foundMatch = regexMatcher.matches()
// loop end

Трудно сказать, будет ли какое-либо существенное улучшение производительности.

Answer 7

Это звучит как преждевременная оптимизация.

Напишите наиболее простой код, какой только сможете, затем профилируйте его в реалистичных настройках и посмотрите, есть ли проблемы с производительностью или схемами распределения памяти. Если есть, решите конкретные проблемы, которые вы обнаружили.

Современные JVM невероятно хороши в сборке мусора недолговечных объектов.