{"id":17050,"date":"2023-11-23T08:27:54","date_gmt":"2023-11-23T07:27:54","guid":{"rendered":"https:\/\/vived.io\/?p=17050"},"modified":"2023-11-24T07:03:31","modified_gmt":"2023-11-24T06:03:31","slug":"spring-framework-6-1-i-spring-boot-3-2-najsmakowitsze-kaski-jvm-weekly-vol-154","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/spring-framework-6-1-i-spring-boot-3-2-najsmakowitsze-kaski-jvm-weekly-vol-154\/","title":{"rendered":"Spring Framework 6.1 i Spring Boot 3.2: najsmakowitsze k\u0105ski – JVM Weekly vol. 154"},"content":{"rendered":"\n

Spring bowiem postanowi\u0142 bowiem dogoni\u0107 reszt\u0119 ekosystemu i wprowadzi\u0142 wsparcie dla dw\u00f3ch bardzo istotnych nowo\u015bci z punktu widzenia wysokowydajnych aplikacji: Wirtualnych W\u0105tk\u00f3w oraz Projektu CRAC.<\/p>\n\n\n\n

Virtual Threads<\/h2>\n\n\n\n

Dobra, jako \u017ce pewnie na ten tekst trafi\u0105 ludzie, kt\u00f3rzy programuj\u0105 w Springu, wi\u0119c z za\u0142o\u017cenia mogli jeszcze nie zapozna\u0107 si\u0119 jeszcze z konceptem Wirtualnych W\u0105tk\u00f3w (bo takowych w ekosystemie za bardzo jeszcze nie by\u0142o), bardzo kr\u00f3tkie wprowadzenie do tematu.<\/p>\n\n\n\n

Wirtualne W\u0105tki, wprowadzone w JDK 21 w ramach Projektu Loom, mieszaj\u0105 w podej\u015bciu Javy do wsp\u00f3\u0142bie\u017cno\u015bci. W przeciwie\u0144stwie do tradycyjnych w\u0105tk\u00f3w, kt\u00f3re s\u0105 bezpo\u015brednio zarz\u0105dzane przez system operacyjny i s\u0105 stosunkowo ci\u0119\u017ckie (gdzie to s\u0142owo rozumiem tutaj jako „generyczne”, w\u0105tki wirtualne s\u0105 lekkie i zarz\u0105dzane przez JVM. Pozwala to na tworzenie du\u017cej liczby w\u0105tk\u00f3w bez narzutu, kt\u00f3re zwykle wi\u0105\u017ce si\u0119 z tradycyjnymi w\u0105tkami. Virtual Thready s\u0105 szczeg\u00f3lnie korzystne w aplikacjach intensywnie korzystaj\u0105cych z I\/O, umo\u017cliwiaj\u0105c im obs\u0142ug\u0119 wsp\u00f3\u0142bie\u017cno\u015bci przy zmniejszonym zu\u017cyciu pami\u0119ci, szczeg\u00f3lnie w scenariuszach zwi\u0105zanych z operacjami blokuj\u0105cymi. Oczywi\u015bcie to tylko wierzcho\u0142ek g\u00f3ry lodowej, wi\u0119c je\u015bli chcecie o Wirtualnych W\u0105tkach dowiedzie\u0107 si\u0119 wi\u0119cej, idealnym miejscem b\u0119dzie, jak sama nazwa wskazuje, The Ultimate Guide to Java Virtual Threads<\/a>, gdzie zamiast jednego akapitu jak tutaj macie po prostu godzin\u0119+ czytania. Bo z wirtualnymi w\u0105tkami jest jednak jak z t\u0105 legendarn\u0105 sow\u0105 – za\u0142o\u017cenia s\u0105 proste, interesuj\u0105co robi si\u0119 gdy trafiamy na szczeg\u00f3\u0142y.<\/p>\n\n\n

\n
\"\"
Chocia\u017c akurat ten mem to si\u0119 mocno zestarza\u0142 na naszych oczach<\/figcaption><\/figure><\/div>\n\n\n

Spring eksperymentowa\u0142 z tymi w\u0105tkami ju\u017c dawno, kiedy znanymi jako Fibers (kurcze, stary jestem, jeszcze w 2018 mia\u0142em o nich talka<\/a>). Zamiast jednak rzuci\u0107 si\u0119 na ca\u0142o\u015b\u0107 jak sroka na b\u0142yskotki, podej\u015bcie Springa obejmuje bardziej ewolucyjn\u0105 rewizj\u0119 modeli wsp\u00f3\u0142bie\u017cno\u015bci w frameworku, tak aby wykorzysta\u0107 wirtualne w\u0105tki bez wywracania API do g\u00f3ry nogami.<\/p>\n\n\n\n

Wsparcie w Springu jest wi\u0119c warunkowe i zale\u017cy od dw\u00f3ch czynnik\u00f3w: uruchomienia aplikacji z u\u017cyciem JDK 21 oraz w\u0142\u0105czenia opcji konfiguracyjnej spring.threads.virtual.enabled<\/code>. Wtedy to zar\u00f3wno serwery Tomcat, jak i Jetty w Spring Boot u\u017cywaj\u0105 w\u0105tk\u00f3w wirtualnych do przetwarzania zapyta\u0144. Oznacza to, \u017ce kod aplikacji, jak cho\u0107by metody kontroler\u00f3w obs\u0142uguj\u0105ce requesty sieciowe, b\u0119dzie dzia\u0142a\u0142 na w\u0105tkach wirtualnych, oferuj\u0105c potencjalne lepsz\u0105 w wydajno\u015bci aplikacji (aczkolwiek osobi\u015bcie sugeruje sprawdzi\u0107 to bardziej empirycznie, ka\u017cda aplikacja mo\u017ce mie\u0107 nieco inne bootlenecki).<\/p>\n\n\n\n

To jednak nie koniec: integracja w\u0105tk\u00f3w wirtualnych w Spring obejmuje te\u017c troch\u0119 dodatkowych atrakcji. Powsta\u0142 dedykowany a dedicated VirtualThreadTaskExecutor<\/code>, a gdy w\u0105tki wirtualne s\u0105 w\u0142\u0105czone, zar\u00f3wno SimpleAsyncTaskExecutor<\/code> jak i SimpleAsyncTaskScheduler<\/code> skonfigurowane zostaj\u0105 domy\u015blnie do ich u\u017cycia. Afektuje to sporo zachowa\u0144 Springa, w tym metod u\u017cycia metod @EnableAsync<\/code>, asynchronicznego przetwarzania \u017c\u0105da\u0144 w Spring MVC oraz wsparcia dla blokuj\u0105cego wykonania w Spring WebFlux. Wp\u0142ywa to te\u017c na dzia\u0142anie poszczeg\u00f3lnych integracji, takich jak listenery dla RabbitMQ czy Kafki, Spring Data Redis oraz Apache Pulsar (o kt\u00f3rym za chwil\u0119). Przyznam, \u017ce z mojej strony brakuje mi troch\u0119 wi\u0119kszej granularno\u015bci i mo\u017cliwo\u015bci wyboru, w kt\u00f3rych miejscach realnie chcemy Wirtualnych W\u0105tk\u00f3w u\u017cywa\u0107 – u\u0142atwi\u0142oby to z pewno\u015bci\u0105 migracje wi\u0119kszych projekt\u00f3w. C\u00f3\u017c, mo\u017ce w kolejnych edycjach.<\/p>\n\n\n\n

Sam Spring na razie nie opublikowa\u0142 konkretniejszych analiz wp\u0142ywu Virtual Thread\u00f3w na aplikacje webowe, ale jako \u017ce konkurencja ju\u017c ten temat rozgrzebywa\u0142a polecam \u015bwietn\u0105 seri\u0119 od Quarkusa<\/a> – implikacje i dobre praktyki powinny by\u0107 zbli\u017cone.<\/p>\n\n\n

\n
\"\"
Bo Spring to jest takie Apple \u015bwiata JVM – wprowadza technologie dopiero wtedy, jak ju\u017c si\u0119 mocno u konkurencji wygrzej\u0105.<\/figcaption><\/figure><\/div>\n\n\n

Project CRAC<\/h2>\n\n\n\n

Zanim b\u0119dzie o drugiej wa\u017cnej nowo\u015bci, projekcie CRaC, najpierw musz\u0119 wspomnie\u0107 o tym czym jest tak zwany problem Zimnego Startu.<\/p>\n\n\n\n

Jak pewnie wiecie, \u017ce aplikacje napisane w Javie \u2013 zanim jeszcze b\u0119d\u0105 w stanie \u201eprzyjmowa\u0107\u201d ruch \u2013 zwykle potrzebuj\u0105 troch\u0119 czasu na rozruch. Cechuje to zar\u00f3wno klasyczne aplikacje serwerowe (kt\u00f3re do osi\u0105gni\u0119cia pe\u0142nej wydajno\u015bci wymagaj\u0105 procesu kompilacji JiT, odpalanej na bazie dynamicznej charakterystyki ruchu), jak i aplikacji Serverless (kt\u00f3re po prostu w sytuacjach brzegowych wymagaj\u0105 ca\u0142ej maszynerii pod spodem). <\/p>\n\n\n

\n
\"\"
Cho\u0107 i na to chc\u0105cy znajdzie spos\u00f3b.<\/figcaption><\/figure><\/div>\n\n\n

Na szcz\u0119\u015bcie, istnieje kilka rozwi\u0105za\u0144 kt\u00f3re ten „zimny start” nam zredukuj\u0105 – taki GraalVM pozwala nam na tworzenie „natywnych” wersji aplikacji Java, ale istniej\u0105 te\u017c metody jak Fast Startup czy AppCDS s\u0142u\u017cy\u0142y do cache\u2019owania poszczeg\u00f3lnych fragment\u00f3w runtime JVM-a, aby nie trzeba by\u0142o ich inicjowa\u0107 od zera przy starcie. Co jednak, je\u015bli mogliby\u015bmy za ka\u017cdym razem odczytywa\u0107 rozgrzany, od\u0142o\u017cony na p\u00f3\u017aniej kod aplikacji, a mo\u017ce i kompletn\u0105 pami\u0119\u0107 ju\u017c z wczytanymi danymi, cho\u0107by dla modeli ML? By to osi\u0105gn\u0105\u0107, na naszym radarze powinno pojawi\u0107 si\u0119 mechanizm, CRIU.<\/p>\n\n\n\n

Checkpoint\/Restore in Userspace (CRIU) to funkcja Linuxa, kt\u00f3ra umo\u017cliwia wykonanie \u201ezrzutu\u201d na dysk ca\u0142ego dzia\u0142aj\u0105cego procesu aplikacji. Nast\u0119pnie, kolejna instancja mo\u017ce by\u0107 uruchomiona z tego punktu, w kt\u00f3rym wykonano wspomniany zrzut, co skraca czas rozruchu.<\/p>\n\n\n\n

Mam w\u015br\u00f3d czytelnik\u00f3w jakich\u015b retro-graczy? Je\u015bli tak, to ca\u0142o\u015b\u0107 dzia\u0142a w podobny spos\u00f3b jak funkcjonalno\u015b\u0107 Save State w emulatorach. Metody takie jak AppCDS przypominaj\u0105 klasyczne zapisywanie \u2013 wybieramy te fragmenty, kt\u00f3re pozwol\u0105 nam p\u00f3\u017aniej odtworzy\u0107 stan aplikacji, i tylko je zapisujemy. Save State nie bawi si\u0119 w takie finezje \u2013 jako, \u017ce komputery posz\u0142y do przodu i mamy wi\u0119cej przestrzeni dyskowej, to po prostu zrzucamy ca\u0142y stan pami\u0119ci na dysk (co w wypadku starych konsol mo\u017ce by\u0107 np. zawrotnym 1Mb) i potem sobie odtwarzamy 1:1 gdy jest to potrzebne.<\/p>\n\n\n

\n
\"\"
Tak dzia\u0142a r\u00f3wnie\u017c w\u0142a\u015bnie CRIU.<\/figcaption><\/figure><\/div>\n\n\n

CRIU posiada swoje problemy \u2013 zar\u00f3wno z punktu widzenia bezpiecze\u0144stwa, jak i wygody u\u017cytkowania \u2013 m\u00f3wimy tutaj bowiem o generycznej funkcji systemu operacyjnego, znajduj\u0105cej si\u0119 poza JVM. Ka\u017cda aplikacja ma za\u015b nieco inn\u0105 charakterystyk\u0119 i w zale\u017cno\u015bci od tego, czy m\u00f3wimy o serwerze aplikacyjnym, aplikacji webowej czy batchowym jobie zapis na dysk powinien odbywa\u0107 si\u0119 w innym momencie, kt\u00f3ry mo\u017ce by\u0107 trudny do wychwycenia bez kontekstu maszyny wirtualnej. Jak pisze OpenLiberty w swoim tek\u015bcie Faster start-up for Java applications on Open Liberty with CRIU<\/a>:<\/p>\n\n\n\n

\n

It would be useful to have an API so that the application can specify when it would like a snapshot to be taken; this would be a valuable addition to the Java specification.<\/p>\n<\/blockquote>\n\n\n\n

OpenLiberty od tamtem pory dorobi\u0142o si\u0119 w\u0142asnego mechanizmu u\u017cywaj\u0105cego CRIU.<\/p>\n\n\n\n

\n