Change JMeter properties backend to a lock-free representation to avoid run-time lock contention

[rajat315315]

Use case

Description

In high-concurrency performance testing scenarios, global property queries performed during active test execution (for example, through JSR223 Groovy scripts accessing the implicit props object or through ${__P()} / ${__property()} functions) create a global synchronization bottleneck.

java.util.Properties inherits directly from java.util.Hashtable, where core accessors like .get(Object) and mutators like .put() are declared as synchronized methods. In highly concurrent test plans (e.g. 500+ threads executing JSR223 elements concurrently), threads end up serialization-blocked waiting to acquire the monitor lock of the global properties instance.

Possible solution

Introduce a subclass of java.util.Properties named ConcurrentProperties which internally delegates read queries to a backing ConcurrentHashMap, while keeping writes synchronized and in sync with the parent Hashtable data model. This provides completely lock-free read lookups under concurrent scripts while maintaining full type compatibility (instanceof java.util.Properties).

Possible workarounds

No response

JMeter Version

6.0.0-SNAPSHOT

Java Version

No response

OS Version

No response