Java 7 w akcjiJava 7 in action Wreszcie znalazłem wolną chwilę by wypróbować w praktyce nowe ficzery Java 7. Zabawy z wersją beta najnowszego jdk ułatwia NetBeans IDE 7.0 Beta 2. Do testów na pierwszy ogień poszły usprawnienia...

Readmore

Monitoring podstawowych parametrów JVM z poziomu web... Problem Monitoring podstawowych parametrów JVM z poziomu web aplikacji - przydatne zwłaszcza wtedy, gdy nasz serwer aplikacji/kontener serwletów nie pokazuje takich informacji w swojej webowej konsoli...

Readmore

Vaadin vs Richfaces i o tym co z tego wyszło [Java... Głośno ostatnio na DWorld i DZone zrobiło się o nowej odsłonie Vaadina - frameworku opartego na GWT. Nigdy wcześniej nie miałem styczności z GWT (prócz kilku tutoriali i paru hellowordów). Pracuję...

Readmore

Jak wyciągnąć kilka pierwszych wyników zapytania... [sql] -- Oracle select a.* from (select rownum row_num, t.* from t_table t ) a where a.row_num <= N -- DB2 select * from t_table fetch first 10 rows only -- Informix select...

Readmore

Vademecum IBM i oraz darmowe konto na iSeriesIBM i... Znalazłem jakiś czas temu 'hosting' oparty o iSeries, na którym można założyć sobie darmowe konto. Gdyby ktoś zatem poczuł nieodpartą pokusę pobawienia się AS/400 Green Screen, to ma taką...

Readmore

twitter

(Polski) Singleton z double-checked locking oraz problem z wielowątkowością w TestNG

Category : java

Wyczytałem ostatnio w mądrych książkach, że synchronizacja singletonów na poziomie metody getInstance może w środowisku wielowątkowym znacznie (25%) spowolnić pobieranie instancji obiektu przechowywanego przez owy singleton. W przypadku, gdy wydajność ma dla nas kluczowe znaczenie, do tworzenia singletonów zalecano stosowanie wzorca double-checked locking. Jak to przeczytałem chciałem sobie sprawdzić o ile rzeczywiście mechanizm synchronizacji spowalnia cały proces. Napisałem więc trzy singletony:

tradycyjny

i dwie różne implementacje double-checked locking

Przetestowałem ich działanie poniższym testem dla różnej ilości wątków (100-10000):

Co dziwne, czasowe wyniki działania tych testów były właściwie identyczne, lub różnica była zaniedbywalna. Testy przeprowadzałem na . Nie testowałem wydajności na Java 1.4 bo istnieje prawdopodobieństwo wystąpienia problemu błędnej implementacji volatile.

Zastanawiam się zatem, dlaczego nie mogę zobaczyć tej ‘nieefyktowności synchronizacji’ getInstance z SimpleSingleton.java. Być może kompilator JIT zoptymalizował mi kod którejś z moich metod getInstance, nie umiem użyć wielowątkowości w TestNG, albo może jest jakaś inna przyczyna, o której nie mam zielonego pojęcia?

Aby wyeliminować moją ewentualną nieumiejetność posługiwania sie TestNG, dopisałem jeszcze metody testujące, w których ciele samemu n razy pobieram w nowych wątkach instancję obiektu z singletona:

Tutaj też nie widać w ogóle spadku wydajności synchronizacji na poziomie całej metody. Znajdzie się ktoś życzliwy, kto naprowadzi mnie gdzie w toku mojego ‘myślenia’ jest błąd? :)

Projekt eclise: pobierz

Comments (1)

Proponuję byś zapytał na liście mailingowej TestNG.


pozdrawiam
Tomek

Post a comment