Modyfikator final, a synchronizacja

Modyfikator final, a synchronizacja
Qbisiek
  • Rejestracja:około 12 lat
  • Ostatnio:około 10 lat
  • Postów:160
0

Krótkie pytanie: Czy jeżeli mam pole z modyfikatorem final - czyli stałą, to nie ma możliwości, żeby dwa wątki dostały się do niej jednocześnie i jakoś dwukrotnie przypisały wartość?
Innymi słowy, czy jest to 100%-owy Singleton (tzn. wątki nie mogą popsuć idei Singletona)? :

Kopiuj

public class Singleton
{
	public static final Singleton INSTANCE = new Singleton();
	
	private Singleton()
	{

	}
}


edytowany 2x, ostatnio: Qbisiek
Shalom
  • Rejestracja:około 21 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
0

Pytanie nie ma nic wspólnego z kodem. W takim kodzie inicjalizacja następuje przy tworzeniu klas (nie obiektów!) bo pole jest statyczne. final nie ma tu żadnego znaczenia.
To co pokazałeś to jest singleton, ale da sie go popsuć jak ktoś umie ;) Na przykład przez serializacje/deserializacje. Ale w normalnym życiu jest ok.


"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
edytowany 1x, ostatnio: Shalom
Qbisiek
  • Rejestracja:około 12 lat
  • Ostatnio:około 10 lat
  • Postów:160
0

Tak, faktycznie z tym staticiem w kodzie moje pytanie miało niewiele wspólnego :P . Niemniej jednak abstrahując od zamieszczonego kodu chciałbym się dowiedzieć czy samo final zmienna = wartość; może zostać popsute (przypisanie wielokrotnie wartości) przez wątki, które w tym samym czasie chcą ją uzyskać?


edytowany 1x, ostatnio: Qbisiek
Patryk27
*abstrahując :P
Qbisiek
no taa, tak lepiej wygląda :)
Shalom
  • Rejestracja:około 21 lat
  • Ostatnio:prawie 3 lata
  • Lokalizacja:Space: the final frontier
  • Postów:26433
0

Nie umiem sobie tego wyobrazić o czym piszesz ;] W jakiej sytuacji miałoby to niby wystąpić?


"Nie brookliński most, ale przemienić w jasny, nowy dzień najsmutniejszą noc - to jest dopiero coś!"
Qbisiek
  • Rejestracja:około 12 lat
  • Ostatnio:około 10 lat
  • Postów:160
0

Kurde... chciałem wysilić się na jakiś przykład, ale to rzeczywiście trudne do wymyślenia :P ...czyli podsumowując zadałem dwa bezsensowne pytania w 2 postach, brawo :)


1

Pola final ktore nie sa statyczne musza byc zainicjowane inline lub w konstruktorze. Zanim konstruktor sie zakonczy, zaden watek nie ma referencji do obiektu, bo to jakby chcieci zeby przed wykonaniem new Object() lub w trakcie juz byla do tego jakas referencje. Ergo, final jest niejawnie thread-safe, tak mi sie wydaje ;d

Shalom
Tak właśnie jest :) Dlatego pytanie autora było bez sensu ;)
Qbisiek
No właśnie o to chciałem spytać - czy "final jest niejawnie thread-safe" :)
n0name_l
Kazdy immutable obiekt jest thread-safe.
WK
WK
  • Rejestracja:około 11 lat
  • Ostatnio:prawie 10 lat
  • Postów:110
1
mućka napisał(a):

Pola final ktore nie sa statyczne musza byc zainicjowane inline lub w konstruktorze. Zanim konstruktor sie zakonczy, zaden watek nie ma referencji do obiektu, bo to jakby chcieci zeby przed wykonaniem new Object() lub w trakcie juz byla do tego jakas referencje. Ergo, final jest niejawnie thread-safe, tak mi sie wydaje ;d

Nie, nie jest tak. Zgodnie z <a href=http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5.2">Java Language Specification</a> jesli w konstruktorze przekazujesz gdzies referencje do this to calee moze zobaczyc czesciowo zainicjalizowany obiekt.

Shalom
A moze zamiast czytać ostatni post przeczytasz cały wątek? Bo mowa była o sytuacji kiedy ktoś pobiera referencje do danego obiektu a nie sytuacja kiedy w konstruktorze tego obiektu on sam przekazuje komuś swojego this ;]
WK
wojciech.kudla
@shalom odniosłem się ogólnie do stwierdzeń zawartych w zacytowanej wypowiedzi. This jak najbardziej może "uciec" w trakcie inicjalizacji (w konstruktorze) jeszcze przed przypisaniem wartości do pól final. Mówi o tym fragment specyfikacji, na który się powołałem. Pozdr.
Shalom
Oczywiście, ale nie w sytuacji o której mówiliśmy ;)
0

Jasne, że jest atomowe.

WK
WK
  • Rejestracja:około 11 lat
  • Ostatnio:prawie 10 lat
  • Postów:110
1

Pola static inicjalizowane są przez classloader przy ładowaniu klasy. Cała operacja zawarta jest w sekcji krytycznej, więc jesteś bezpieczny. Pamiętaj jednak, że w środowiskach z pełną izoalcją classloaderów (np. osgi) możesz skończyć z kilkoma instancjami singletona :)

Shalom
Nawet w środowisku z jednym, prostym classloaderem da się zrobić kilka singletonów tego typu...
0

Ale dostep z innego classloadera tylko z proxy:-)

WK
wojciech.kudla
Tu nie chodzi o dostęp do tej samej klasy zainicjalizowanej przez różne classloadery, bo to (jak zapewne wiesz) wyrzuciłoby CCE. Chodzi raczej o spójność stanu w ramach różnych modułów jednej aplikacji.

Zarejestruj się i dołącz do największej społeczności programistów w Polsce.

Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.