2017-10-17 4 views
0

Wir für eine Bibliothek/Funktionalität in Java (in einem Federrahmenkontext) suchen Referenzen zwischen Threads vorbei:Java Shared Referenzen zwischen Threads

//ParentThread: 
XXX.putSharedObject("lock", childLock); 
XXX.putSharedObject("someKey", someObjectInstance); 
for(i=0;i<X;i++) { taskExecutor.execute(context.getBean("childClass")); } 
childLock.wait(xxx); 

//ChildThread: 
YY = XXX.getSharedObject("someKey"); 
YY.someFunction(); 
...some work... 
XXX.getSharedObject("lock").notify(); 

so dass jede Referenz durch ein Gewinde in XXX gesetzt (ParentThread) wird nur für "ParentThread" und alle untergeordneten Elemente verfügbar sein, aber nicht für andere ParentThreads oder deren untergeordnete Elemente.

Ist das möglich? (Ich glaube, seine Art, wie Mapped Diagnostic Context Arbeit in Logging Frameworks)

Dank

+0

Mit meiner besten Fähigkeit, Ihre Frage zu parsen, ich glaube, Sie könnten für suchen [ 'java.lang.ThreadLocal'] (https: //docs.oracle.com/javase/8/docs/api/java/lang/ThreadLocal.html) –

+0

Ist das nicht pro Thread selbst? Dh kann die von 'ParentThread' definierte ThreadLocal-Variable von 'ChildThread' aufgerufen werden, ohne sie jedes Mal im Konstruktor zu übergeben? (In diesem Fall eine Bean aus dem Spring-Kontext holen und einen 'Setter' für alle Referenzen aufrufen?) –

+0

Offenbar gibt es eine ['java.lang.InheritableThreadLocal'] (https://docs.oracle.com/javase/ 7/docs/api/java/lang/InheritableThreadLocal.html). –

Antwort

0

gemeinsam benutzte Java können Referenzen mit Thread-Sicherheit mit einer synchronisierten Klasse oder sogar einen Block oder ein Verfahren erreicht werden. Auf diese Weise können Sie ein gegebenes Objekt zwischen Threads (Parent, Child ...) freigeben und die Thread-Sicherheit garantieren.

+0

Thread-Sicherheit ist hier kein Problem (angenommen, zum Beispiel YY.someFunction(); ist threadsicher hier), das Problem ist zu vermeiden Aufrufer Setter für jeden Lader innerhalb der for-Schleife und alle Arten von Threads, die eine Menge von teilen müssen gemeinsame Referenzen. –

+0

Wieder, wie MDC funktioniert in Logging-Bibliotheken (wie Log4J) –

1

es wie folgt (Compliments of M. le Rutte) Arbeitete aus:

//ParentRunnable: 
public static final InheritableThreadLocal<SomeObjectType> YY = new InheritableThreadLocal<SomeObjectType>(); 

@Override 
public void run() { 
    ... 
    YY.set(someObjectInstance); 
    logger.debug("InParent: {}", YY.get()); 
    for(i=0;i<X;i++) { taskExecutor.execute(context.getBean("childClass")); } 
} 


//ChildRunnable: 
@Override 
public void run() { 
    logger.debug("InChild: {}", ParentRunnable.YY.get()); 
} 

Das schöne Teil, dass auch ist:

@Override 
protected SomeObjectType initialValue() 

kann eine Ausnahme auslösen andeuten Aufruf "get()" vorzeitig vor a "set()", oder verwenden Sie den Anwendungskontext, um eine Prototyp-Bean zu erhalten, die als Singleton zwischen den Kindern verwendet wird.

Hoffnung dies jedem hilfreich ist es braucht (und hoffentlich auch richtig geschrieben)