Fix: Reduce thread blocking by double null check instead of synchronizing on Method object

[fanzhongwei]

PR Title

Fix: Reduce thread blocking by double null check instead of synchronizing on Method object

PR Description

Problem

We observed severe thread blocking issues in production: 980+ threads were blocked at OgnlRuntime.invokeMethod with the state BLOCKED (on object monitor), waiting to lock java.lang.reflect.Method objects.

# 980 threads blocked
"default-17571" #91915 prio=5 os_prio=0 tid=0x00007f7b7c05d800 nid=0x167f9 waiting for monitor entry [0x00007f757f772000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.apache.ibatis.ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:1151)
	- waiting to lock <0x00000004a55aaf48> (a java.lang.reflect.Method)
	at org.apache.ibatis.ognl.OgnlRuntime.getMethodValue(OgnlRuntime.java:2146)
	at org.apache.ibatis.ognl.ObjectPropertyAccessor.getPossibleProperty(ObjectPropertyAccessor.java:66)
	at org.apache.ibatis.ognl.ObjectPropertyAccessor.getProperty(ObjectPropertyAccessor.java:160)
	at org.apache.ibatis.ognl.OgnlRuntime.getProperty(OgnlRuntime.java:3356)
	...

# got method lock thread
"HSFBizProcessor-DEFAULT-6-thread-5179" #90650 daemon prio=10 os_prio=0 tid=0x00007f794c319000 nid=0x16214 waiting for monitor entry [0x00007f758366e000]
   java.lang.Thread.State: BLOCKED (on object monitor)
	at org.apache.ibatis.ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:1151)
	- locked <0x00000004a55aaf48> (a java.lang.reflect.Method)
	at org.apache.ibatis.ognl.OgnlRuntime.getMethodValue(OgnlRuntime.java:2146)
	at org.apache.ibatis.ognl.ObjectPropertyAccessor.getPossibleProperty(ObjectPropertyAccessor.java:66)
	at org.apache.ibatis.ognl.ObjectPropertyAccessor.getProperty(ObjectPropertyAccessor.java:160)
	at org.apache.ibatis.ognl.OgnlRuntime.getProperty(OgnlRuntime.java:3356)
	...

Root cause:

• Direct synchronization on Method objects leads to heavy thread contention — all threads competing to execute method access checks must wait for the same Method monitor, which severely degrades system concurrency and performance.

Solution

To resolve the thread blocking while maintaining cache correctness, we introduced a double null check pattern to avoid unnecessary synchronization on Method objects:

1. First check the _methodAccessCache for existing cached values (no synchronization)
2. Only enter the synchronized block if the cache is missing
3. Re-check the cache inside the synchronized block to prevent duplicate initialization (thread-safe)
4. Keep all original business logic for method access checks and cache operations — only optimize the synchronization trigger condition

Key Code Changes

• Moved the synchronized (method) block inside a double null check for methodAccessCacheValue
• Avoid synchronizing on Method objects when the cache is already hit
• Preserved full compatibility with existing cache logic (_methodAccessCache/_methodPermCache)
• Maintained the original logic for syncInvoke calculation and method access check

Expected Outcome

• Significantly reduce thread blocking by eliminating unnecessary locks on Method objects
• Improve concurrency performance of OGNL runtime without breaking existing logic
• Ensure cache atomicity and thread safety via double null check
• No breaking changes — fully compatible with existing usage

Additional Notes

• This change follows the "double-checked locking" best practice for lazy initialization
• No changes to public APIs or behavior — only optimizes internal concurrency
• Tested with MyBatis 3.5.x (the version where the blocking was observed)

[lukaszlenart]

Great, thanks for the patch! I'm going to merge it now and cherry pick changes into 4.8.x branch as well

[lukaszlenart]

PR is ready #523

[fanzhongwei]

Great, thanks for the patch! I'm going to merge it now and cherry pick changes into 4.8.x branch as well

Thank you very much for merging the patch and backporting it to the 4.8.x branch!

I appreciate your attention to getting this optimization out across relevant branches, and feel confident it will help reduce the thread contention issues we observed.

[lukaszlenart]

I meant 3.4.x branch - sorry for mixing things up :(