Java: Dobre praktyki 2

0:00Cześć w tej lekcji kontynuujemy naszą zabawę ze strumieniami z lambdami

0:04oraz częstymi błędami przy ich wykorzystaniu w tym programie tworzymy

0:08sobie strumień zawierający elementy od jednego do 100 i tutaj mapujemy

0:12sobie poszczególne elementy dodajemy je nazywamy te elementy wpadające

0:17jako id i dodajemy sobie jakiś prefiks jakieś e tutaj

0:21małpę i domain name tak czyli generujemy sobie jakieś adresy

0:26mailowe okej i to tutaj działa teraz

0:30zobaczmy jedną rzecz że tutaj wewnątrz tej lambdy wykorzystujemy id

0:35prefiks oraz domain name które są tutaj jakimiś no właśnie zmiennymi

0:40statycznymi tak tej klasy jeżeli chcemy używać

0:44tego w lambdzie to to nam się oczywiście skompiluje zadziała ale

0:49ktoś może nam to zmienić lepszą praktyką jest wykorzystywanie stałych

0:53tutaj tak tutaj tak nie wydaje mi się żebyśmy wewnątrz naszego

0:57programu chcieli zmieniać domain name tak jako jakąś zmienną statyczną tutaj

1:01tak więc dodajemy po prostu public final static tak w tym

1:06miejscu okej i to już jest jak najbardziej taki w porządku fragment

1:10możemy spokojnie sobie tego używać i idźmy dalej tutaj już trochę rozrósł nam

1:14się przykład wyekstrahowaliśmy metodę make adres która skleja ten adres

1:18mamy też metodę sendmail która udaje że wysłała maila po prostu printuje to

1:23na konsolę żeby wysłała i też chcemy jeszcze tutaj zliczyć

1:27liczby wysłanych maili od momentu startu programu tutaj akurat raz tylko

1:32jest taka seria że wysłałam te 100 000 później już nie są wysyłane one się kończą ale

1:36załóżmy że tej klasy można używać z innych klas ona nie powinna

1:40się nazywać main ale powiedzmy teraz jest taki przykład i teraz pytanie czy

1:45takie zliczanie tutaj jeżeli w tej metodzie jest send mail po prostu inkremetujemy to

1:49czy to jest bezpieczne na razie to jest bezpieczne z tego względu że tutaj

1:53ten static jest private tak czyli tylko z tego

1:57miejsca i z tych metod które są w main możemy edytować tak zmieniać

2:02wartość tej zmiennej oraz druga rzecz trochę mi na pierwszy rzut oka

2:06widoczna to to że te metody których używamy wewnątrz

2:10tego strumienia są w tym momencie wykonywane sekwencyjne ponieważ ten strumień

2:14jest sekwencyjny ale jeżeli dodamy tutaj parę tak czyli zamienimy

2:19ten strumień na strumień który jest współbieżny tak

2:23rozproszony no to czy to już nie będziemy mieli tej gwarancji te

2:27elementy metody tutaj które są wykonywane od tego momentu powinny być

2:31thread safety tak czyli powinny być bezpieczne do wykonywania

2:36wielu wątków na raz teraz się przyjrzymy czy są make address tylko

2:40dostaje integera tak jakiś id skleja sobie

2:44stringa i zwraca go tak nie modyfikuje żadnego stanu więc to jest okej

2:48ale jest metoda sendmail która trochę modyfikuje stan zmienia nam tego longa

2:53tutaj teraz jest taki problem że ze względu na to że ten send

2:57mail będzie wykonywany z wielu wątków to możemy dostać pewną anomalię

3:01w tym miejscu odpalmy sobie tutaj tę metodę i zobacz wysłaliśmy

3:05niby 100 000 maili ale nasz counter pokazuje

3:09mniej brakuje tutaj 14 elementów i teraz z czego to wynika

3:14to jest taka anomalia związana z tym że zapis i odczyt tej

3:18zmiennej tutaj nie są atomowe to znaczy może mieć sytuację kiedy dla

3:22najprostszego przykładu dwa wątki na raz spróbuje implementować

3:26send mail tak tego countera jedna sobie wyciąga stan który jest na początku 0

3:31i druga sobie wyciąga zera ale robią to na raz tak i teraz jedna bierze 0

3:35dodaje do niej jedynkę dostaje jedynkę i w tym samym momencie druga też wyciąga

3:39zero dodaje jedynkę i obie zapisują w tym samym momencie jedynkę

3:43no i teraz tak jedna zapisała jedynkę druga nadpisała tę wartość

3:48też jedynką no i mamy w counterze 1 a maili wysłaliśmy 2

3:52to jest taki problem że ten counter który powinniśmy użyć powinien być też

3:56bezpieczny pod względem wątkowości i tak możemy w tym celu

4:00zamiast longa użyć atomic longa w tym więcej się dowiemy już w rozdziale o

4:05wielowątkowości współbieżności atomic long ma taką cechę

4:09że możemy go spokojnie inkrementować z wielu wątków nie zawsze będzie to

4:13super wydajne ale jest to bezpieczne tutaj zamiast przypisywać po prostu

4:17robimy increment get on po prostu poza tym że zwróci ten element

4:21po zinkrementowaniu to bezpiecznie zainkrementuje nam tę wartość możemy

4:25teraz odpalić nasz przykład i już widzimy że mamy 100 000 okej czyli

4:30to już jest ta bezpieczniejsza wersja teraz na potrzeby jeszcze jednej rzeczy wrócimy sobie

4:34do sytuacji kiedy mieliśmy sekwencyjny strumień i tutaj mamy tego

4:38send mail prawda oraz tutaj jeszcze możemy sobie inkrementować

4:42send mail zróbmy inline teraz tej metody send mail z miejsca

4:46żebybyśmy mieli zamiast tej metody po prostu lambdę tutaj okej tak

4:50to wygląda i teraz sprawdźmy co by się stało jeżeli nie

4:54chcemy mieć tego countera tutaj to chciałbym go mieć tutaj zakomentujmy

4:58sobie to na razie tutaj i utwórzmy na poziomie metody main teraz

5:02to co przed chwilą jeszcze działało już teraz nam nie działa dlaczego dlatego

5:07że w javie po wprowadzeniu lambd wprowadzono taki mechanizm

5:11który blokuje nas przed wykorzystaniem wewnątrz lambdy

5:15parametru jakiejś referencji do obiektu który nie jest finalowy

5:19czyli który nie jest stały albo który nie jest efektywnie stały

5:23ale z wyłączeniem że jest musi być to referencja

5:27do obiektu który jest albo parametrem metody tak

5:31czyli w tym momencie mielibyśmy to jako argument albo jest to zmienna lokalna

5:35czyli tak jak tutaj dopóki mieliśmy to na poziomie jakiejś

5:39zmiennej globalnej jakiegoś statica w main'ie to wszystko było

5:43okej wszystko się kompilowało działało ale teraz jeżeli stworzymy to sobie tutaj i tutaj

5:48sobie zainkrementujemy nie musimy nawet inkrementować tego tutaj wewnątrz lambdy

5:52tak ale wystarczy że tutaj już zmienimy send mails plus

5:57plus tak no to już teraz tam to nie działa teraz o co chodzi z

6:01tym że to jest efektywnie final może być albo final czyli mamy parametr który

6:05jest poprzedzony final ale nie musimy tego robić tak tutaj teraz

6:09zadziała pod warunkiem że wartość tej zmiennej tutaj

6:14nie jest nigdy zmieniana w przypadku primitive nie jest zmieniana jego wartość w przypadku

6:18wtedy kiedy to jest referencja na jakiś obiekt to nie jest po prostu pozmieniany po swojemu

6:22to obiekt tutaj może istnieć być coś jakiś obiekt którego zawartość

6:26w środku zmieniamy tak on jest mutowalny ale nigdy nie zmienia

6:30się to co jest pod tym tak co jest pod tą nazwą okej

6:35to jest tak zwane effectivly final okej podsumujmy czego się nauczyliśmy po

6:39pierwsze jeżeli do czegoś referujemy na jakieś statycznej zmiennej

6:43czy powiedzmy do jakiegoś statycznego obiektu no to po pierwsze zadbajmy o to żeby

6:47to był final druga rzecz jeżeli już musimy zmieniać stan tego

6:51czegoś albo wykorzystujemy nie tyle zmienne

6:55statyczne które są dziś poza nami ale na przykład nasze metody korzystając

6:59z jakichś czy to globalnego jakiegoś stanu czy na przykład modyfikują

7:03bazę czy cokolwiek to jeżeli jesteśmy

7:08w środowisku z którego korzysta wiele wątków czyli na przykład masz strumień jest z parallel

7:12to musimy zadbać aby te elementy w mapach i w tych wszystkich

7:16operacjach po kolei wykonywanych były thread safety ostatnią

7:21rzeczą którą się nauczyliśmy jest to że nie do każdego elementu możemy

7:25w ogóle dostać się z poziomu lambdy nie możemy dostać się do

7:29elementów które są nie są final albo które nie są przynajmniej effectively

7:34final tak to tyle na tę lekcję a już w kolejnej

7:38lekcji nauczymy się jak sobie radzić z wyjątkami wewnątrz lambd dzięki wielkie

7:42i do zobaczenia