Czy łączenie obiektów jest przestarzałą techniką?

Bardzo dobrze znam koncepcję łączenia obiektów i zawsze staram się z niej korzystać w jak największym stopniu.

Dodatkowo zawsze myślałem, że pula obiektów jest standardową normą, ponieważ zauważyłem, że sama Java, a także inne frameworki używają pula w jak największym stopniu.

Ostatnio jednak przeczytałem coś, co było dla mnie zupełnie nowe (i sprzeczne z intuicją?)

Ta pula faktycznie pogarsza wydajność programu, szczególnie w aplikacjach współbieżnych, i newzamiast tego zaleca się tworzenie instancji obiektów, ponieważ w nowszych maszynach JVM tworzenie instancji obiektu jest naprawdę szybkie.

Przeczytałem to w książce: Java Concurrency in Practice

Teraz zaczynam zastanawiać się, czy coś tu nie rozumiem, ponieważ pierwsza część książki zalecała użycie Executorstego ponownego użycia Threadzamiast tworzenia nowych instancji.

Czy pule obiektów są obecnie przestarzałe?

Jest to przestarzała technika ogólna, ponieważ - jak zauważyłeś - tworzenie i niszczenie krótko żyjących obiektów per se (tj. Alokacja pamięci i GC) jest niezwykle tanie we współczesnych maszynach JVM. Tak więc użycie odręcznej puli obiektów dla obiektów typu mill-of-the-mill jest najprawdopodobniej wolniejsze, bardziej skomplikowane i bardziej podatne na błędy niż zwykłe new. *

Nadal jednak ma zastosowanie w przypadku obiektów specjalnych, których tworzenie jest stosunkowo kosztowne, takich jak połączenia DB / sieciowe, wątki itp.

* _{Kiedyś musiałem poprawić wydajność przeszukiwalnej aplikacji Java. Dochodzenie ujawniło próbę użycia puli obiektów do przydzielenia milionów obiektów ... a sprytny facet, który ją napisał, użył jednej globalnej blokady, aby zapewnić bezpieczeństwo wątków. Zastąpienie puli zwykłym newsprawiło, że aplikacja była 30 razy szybsza.}

Odpowiedź na konkretne pytanie: „Czy łączenie obiektów jest przestarzałą techniką?” jest:

Nie. Pule obiektów są szeroko stosowane w określonych miejscach - pule wątków, pule połączeń z bazami danych itp.

Ogólne tworzenie obiektów nigdy nie było procesem powolnym. Samo gromadzenie zasobów pochłania zasoby - pamięć i moc obliczeniową. Każda optymalizacja jest kompromisem.

Zasada jest następująca:

Przedwczesna optymalizacja jest zła !!!

Ale kiedy dana optymalizacja jest przedwczesna?

Przedwczesna optymalizacja to jakakolwiek optymalizacja przeprowadzona, zanim odkryjesz wąskie gardło poprzez dokładne profilowanie .

W sytuacjach, w których chcesz całkowicie uniknąć wyrzucania elementów bezużytecznych, myślę, że pule obiektów są jedyną realną alternatywą. Więc nie, to absolutnie nie jest przestarzała technika.

Pomiar

Zależy to całkowicie od przypadku użycia, wielkości obiektów, JVM, opcji JVM, włączonej GC i całego szeregu innych czynników.

W skrócie: zmierz go wcześniej, a następnie zmierz. Zakładając, że używasz frameworku obiektów (jak z Apache), przełączanie między implementacjami nie powinno być zbyt bolesne.

Dodatkowa wskazówka dotycząca testowania wydajności - pozwól JVM trochę się rozgrzać, uruchom testy na uruchomionej maszynie JVM kilka razy, może zachowywać się inaczej.

Ta pula faktycznie pogarsza wydajność programu, szczególnie w aplikacjach współbieżnych, i wskazane jest tworzenie instancji nowych obiektów, ponieważ w nowszych maszynach JVM tworzenie instancji obiektu jest naprawdę szybkie.

Zależy od kontekstu.

Nie wiem, czy istnieje zmieniając trend tutaj, ale jego na pewno będzie tak, że to zależy . Jeśli klasa Java zarządza zasobem zewnętrznym, takim jak połączenie RMI lub ładowanie pliku zasobów itp. - z pewnością koszty tworzenia instancji obiektu mogą być nadal wysokie (chociaż zasoby te mogą być już dla Ciebie połączone!). Jako ogólną praktykę zgodziłbym się z książką.