Oglądam bardzo ciekawy wykład:
Nie wiem czy dobrze nazwałem temat. Głównie chodzi mi o wytłumaczenie tego co gość określił jako:
Mutability is ok, sharing is nice, shared mutability is devils work
List<Integer> numbers = Arrays.asList(1,2,3,4,5,1,2,3,4,5);
List<Integer> doubleOfEven = new ArrayList<>();
numbers.stream()
.filter(e -> e % 2 == 0)
.map(e -> e * 2)
.forEach(e - > doubleOfEven.add(e));
Dlaczego to jest złe rozwiązanie? Ktoś może mi to wytłumaczyć łopatologicznie? :)
Jeżeli założymy że wątki mogą się zmienić to
shared mutability is devils work
jest kluczem to przewidywalnych wyników :D JMM nie daje gwarancji . Jeżeli lista zostanie stworzona w wątku A przekazana do B zmiany wykonane w A mogą nie być widoczne.
Mam wrażenie że gościu się zwyczajnie pomylił, i miało być:
numbers.parallelStream()
Wtedy faktycznie zaszłoby spólne używanie mutowalnego obiektu i faktycznie collecor rozwiązałby sprawę.
Jeżeli lista zostanie stworzona w wątku A przekazana do B zmiany wykonane w A mogą nie być widoczne.
Lista zostanie stworzona na stercie i oba wątki będą widziały dokładnie to samo. Inna sprawa że zawartość listy może być niespójna.
Tu chodzi o coś trochę innego niż pisze @krzysiek050, ale za pomocą współbieżnego streama najłatwiej to pokazać.
Obiekt reprezentowany przez doubleOfEven jest niejawnie współdzielony przez kod na dwóch poziomach – w lambdzie i w zakresie reprezentowanym przez cały listing. W ten sposób doszło do sytuacji, że nie jesteś w tanie powiedzieć co tak naprawdę zawiera ta zmienna aż do momentu gdy zakończy się cała iteracja. W efekcie może dojść do sytuacji gdy jakiś inny obiekt próbuje coś z tej listy czytać i nie wie co w niej tak naprawdę jest.
@Koziołek To co przedstawiasz nie odnosi się przypadkiem do każdego domknięcia?
maryiusz napisał(a):
Lista zostanie stworzona na stercie i oba wątki będą widziały dokładnie to samo. Inna sprawa że zawartość listy może być niespójna.
a co ja napisałem ? lol
Że jeden wątek widzi coś innego niż drugi. Coś co może wystąpić przy optymalizacjach JVM jeżeli korzystasz z zmiennej wewnątrz obiektu która nie jest oznaczona volatile. lol
@krzysiek050, technicznie tak, bo tu powinno być collect. Generalnie domknięcia nie powinny modyfikować obiektów z poza swojego zakresu. Inaczej może być nieciekawie.
Że jeden wątek widzi coś innego niż drugi. Coś co może wystąpić przy optymalizacjach JVM jeżeli korzystasz z zmiennej wewnątrz obiektu która nie jest oznaczona volatile. lol
Bzdury,
Wątek A tworzy ArrayListe - wywoływany jest konstruktor i poprawnie stworzony obiekt jest widoczny dla wszystkich wątków (jest OK - JMM nam to gwarantuje) - następnie do tej listy dodawana jest zmienna X, referencja jest przekazywana do następnego (JUŻ istniejącego - to ważne bo thread.start() nawiązuje happened-before relation) wątku - dalej - już mam nie konsystencje bo aktualny wątek nie musi widzieć dodanej wcześniej zmiennej, bo nic nie wywołało store barrier (czyli widzi coś INNEGO niż poprzedni).
Coś co może wystąpić przy optymalizacjach JVM
Od kiedy JVM zarządza cachami procesora ? Ty masz na myśli reordering a pole oznaczone volotile najzwyczajniej odpala store barrier na pisaniu i load barrier na czytaniu, to nie blokuje JVMa przed optymalizacjami... reordering w przypadku o którym piszę nie będzie miał żadnego znaczenia bo operacje następują po sobie sekwencyjnie, mogą mieć JEDYNIE różny stan obiektów w pamięci(cache).
forEach), modyfikuje obiekt, który pochodzi z poza jej zakresu. W bytecodzie masz wielokrotne wywołanie metody w rodzajulambdaWForEach(this, doubleOfEven). Modyfikacja listy, która jest parametrem metody.