Этот PropertyUtils код из OGNL написан как поточно-ориентированный, и поэтому я предполагаю, что скомпилированные выражения предназначены для поточно-ориентированного.
Еще одним свидетельством является то, что большая часть API доступа предоставляет изменяемое состояние в качестве параметра контекста (например, см. PropertyAccessor ), поэтому сами классы имеют небольшое изменяемое состояние. Неизменяемые классы по своей природе поточно-ориентированы. Руководство разработчика призывает расширения быть потокобезопасными, и, наконец,
просматривая код, где есть изменяемое состояние, он охраняется в синхронизированном блоке, например, см. EvaluationPool .
Таким образом, кажется, что OGNL был разработан, чтобы быть потокобезопасным. Является ли это на самом деле или нет, это другой вопрос! Вы можете написать быстрый тест, чтобы убедиться, например, Concutest . В качестве альтернативы, если число потоков разумно, хранение всех выражений в ThreadLocal полностью обходит проблему, за счет небольшой дополнительной памяти (или, возможно, нет, поскольку OGNL выполняет кэширование выражений).