Spring Data Repository Multi-Threading-Leistung

Question

Ich stoße auf ein Leistungsproblem mit mehreren Threads, die auf dasselbe Federdaten-Repository-Objekt zugreifen. Viele der Threads werden blockiert, während auf eine Sperre für das Repository-Objekt gewartet wird. Die meisten Threads führen dieselbe Abfrage für das Repository-Objekt durch. Wenn dieser Threadblock ausgeführt wird, ist die CPU auf allen Kernen ausgelastet. Gelegentlich wird es einbrechen, was ich glaube von den blockierten Threads, die auf eine Sperre für das Repository-Objekt warten. Ich habe durch Profiling überprüft, dass mehrere Threads darauf warten, dieselbe Methode im Repository-Objekt aufzurufen. Ich habe einen Leistungsschub gesehen, als ich den Ansatz geändert habe, die Methode zu verwenden, die eine Liste zurückgibt. Aber die Verriegelung ist immer noch ein Flaschenhals.

UPDATE: Nach mehr Forschung bin ich zu der Schlussfolgerung gekommen, dass das Repository-Objekt ein Singleton ist. Dieses Objekt wird gesperrt, wenn jeder Thread darauf zugreift. Wie prototype ich das Repository-Objekt? (Ich würde ein Read-Only-Repository für diesen Anwendungsfall erstellen.) Müsste die Konfiguration geändert werden? Machen Spring-Daten das schon?

MWE:

public interface EntityJpaRepository extends JpaRepository<Entity, Integer> { 
    @Query(value = "select * from SomeTable where id = (?1);", nativeQuery = true) 
    Entity findById(int id); 

    //Method that returns a list of Entities 
    @Query(value = "select * from SomeTable where id in (?1);", nativeQuery = true) 
    List<Entity> findAllWithIds(List<Integer> ids); 
} 

@Component 
@Scope("prototype") 
public class AThread implements Runnable { 
    @Autowired 
    EntityJpaRepository myRepository; 

    final int someId;   

    public AThread(int someId) { 
     this.someId = someId; 
    } 

    @Override 
    public void run() { 
     //may call subMethod 1 
     myRepository.findById(someId); 
     //may call subMethod 1 
     List<Integer> ids = someMethodWhichReturnsIDs(); 
     myRepository.findAllWithIds(ids); 
     //may call subMethod 1 
    } 

    public void subMethod1(){ 
     //sometimes loop 
     subMethod2(); 
     //may call 
    } 
    public void subMethod2(){ 
     //more stuff 
     List<Integer> ids = someMethodWhichReturnsIDs(); 
     //more stuff 
    } 
} 

public static void main(String[] args){ 
ThreadPoolTaskExecutor taskExecutor = (ThreadPoolTaskExecutor) ctx.getBean("taskExecutor"); 

List<int> someInts;//assume this is full of ints. 
for(int someId: someInts){ 
    taskExecutor.execute((Runnable)ctx.getBean("AThread", someId)); 
} 
waitThreads(taskExecutor); 

Ich werde sagen, ich bin ein gutes Stück von Leistung bekommen von dem, was ich im Moment haben. Ich bin auch nicht sicher, ob ich meine Konfiguration korrekt eingerichtet habe, um die Datenbank mit mehreren Threads/Verbindungen zu treffen. Ich denke nicht, dass das das Problem ist, aber ich habe die vollständige Konfiguration zur Verfügung gestellt. Irgendwelche Tipps für die Leistung sind willkommen.

Hier ist eine Stack-Ablaufverfolgung eines Threads, wenn ich den Prozess/Anwendung anhalten, während es blockiert ist. Ich habe auch eine Beispielausgabe vom Pro-Filer. Wenn es länger läuft, summiert sich die blockierte Zeit. Es wird eindeutig von einem anderen Thread im @Autowired-Repository-Objekt blockiert. Ich dachte, ich hätte das vermieden, indem ich den Prototypumfang benutzt habe.

taskExecutor-1 BLOCKED 4.68003 6320 34 2062 1 java.lang.Object@5842edfa taskExecutor-9 


java.lang.ClassLoader.loadClass(Unknown Source) 
sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) 
java.lang.ClassLoader.loadClass(Unknown Source) 
org.springframework.util.ClassUtils.isVisible(ClassUtils.java:1209) 
org.springframework.util.ClassUtils.getAllInterfacesForClassAsSet(ClassUtils.java:1136) 
org.springframework.util.ClassUtils.getAllInterfacesForClassAsSet(ClassUtils.java:1143) 
org.springframework.util.ClassUtils.getAllInterfacesForClass(ClassUtils.java:1099) 
org.springframework.orm.jpa.SharedEntityManagerCreator$SharedEntityManagerInvocationHandler.invoke(SharedEntityManagerCreator.java:302) 
com.sun.proxy.$Proxy41.createNativeQuery(Unknown Source) 
org.springframework.data.jpa.repository.query.NativeJpaQuery.createJpaQuery(NativeJpaQuery.java:65) 
org.springframework.data.jpa.repository.query.AbstractStringBasedJpaQuery.doCreateQuery(AbstractStringBasedJpaQuery.java:72) 
org.springframework.data.jpa.repository.query.AbstractJpaQuery.createQuery(AbstractJpaQuery.java:165) 
org.springframework.data.jpa.repository.query.JpaQueryExecution$SingleEntityExecution.doExecute(JpaQueryExecution.java:197) 
org.springframework.data.jpa.repository.query.JpaQueryExecution.execute(JpaQueryExecution.java:74) 
org.springframework.data.jpa.repository.query.AbstractJpaQuery.doExecute(AbstractJpaQuery.java:98) 
org.springframework.data.jpa.repository.query.AbstractJpaQuery.execute(AbstractJpaQuery.java:89) 
org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:421) 
org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:381) 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) 
org.springframework.data.repository.core.support.RepositoryFactorySupport$DefaultMethodInvokingMethodInterceptor.invoke(RepositoryFactorySupport.java:512) 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) 
org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99) 
org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:281) 
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96) 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) 
org.springframework.dao.support.PersistenceExceptionTranslationInterceptor.invoke(PersistenceExceptionTranslationInterceptor.java:136) 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) 
org.springframework.data.jpa.repository.support.CrudMethodMetadataPostProcessor$CrudMethodMetadataPopulatingMethodIntercceptor.invoke( CrudMethodMetadataPostProcessor.java:122) 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) 
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:92) 
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179) 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:213) 
com.sun.proxy.$Proxy81.findAllWithIds(Unknown Source) 
sun.reflect.GeneratedMethodAccessor64.invoke(Unknown Source) 
sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) 
java.lang.reflect.Method.invoke(Unknown Source) 
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:333) 
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:207) 
com.sun.proxy.$Proxy90.findAllWithIds(Unknown Source) 
org.somepackage.AThread.subMethod2(AThread.java:696) 
org.somepackage.AThread.subMethod1(AThread.java:346) 
org.somepackage.AThread.run(AThread.java:132) 
java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) 
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) 
java.lang.Thread.run(Unknown Source) 

Answer 1

Das sieht sehr ähnlich wie ein Problem mit dem Laden der Klasse Ihrer Abfrage wiederholt. Wiederholte Lasten derselben Klasse können zu schweren Konflikten auf dem Klassenladerschloss führen. (Beispiel hier: https://plumbr.eu/blog/locked-threads/classloading-and-locking)

Die sharedEntityManager laden die Klasse in Zeile 302 - und dies läuft in den synchronisierten Block auf der Linie 404 in dem Classloader