When searching for errors, I came across Spring 3.0.5 the source code of DelegatingFilterProxy
, and I am wondering if it has a performance bottleneck or not.
Given that for each web application there is only one instance of the delegation of FilterProxy (for the declaration of <filter>
, of course), I must assume that under heavy load many workflows try to call the doFilter()
method in parallel.
Now take a look at the code:
public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws ServletException, IOException { // Lazily initialize the delegate if necessary. Filter delegateToUse = null; synchronized (this.delegateMonitor) { if (this.delegate == null) { WebApplicationContext wac = findWebApplicationContext(); if (wac == null) { throw new IllegalStateException("No WebApplicationContext found: no ContextLoaderListener registered?"); } this.delegate = initDelegate(wac); } delegateToUse = this.delegate; } // Let the delegate perform the actual doFilter operation. invokeDelegate(delegateToUse, request, response, filterChain); }
The synchronized (this.delegateMonitor)
block synchronized (this.delegateMonitor)
must be passed by all threads, which means that all workers are forced to endure the queue in the queue until they are allowed to enter.
Regardless of why you need to search for a bean here, I suspect that using synchronized
could have been avoided in favor of parallel execution - maybe do this.delegate
volatile and use synchronization only if the search needs to be performed.
So am I barking the wrong tree? Any input is appreciated.
source share