Analiza pytań i odpowiedzi z rozmów kwalifikacyjnych dla programisty Java. Część 1

Cześć! Różni ludzie zebrali się w JavaRush. Niektórzy z nas chcą po prostu zostać programistami Java, inwestując dużo czasu i wysiłku w rozwój, podczas gdy inni są już programistami Java. W takim czy innym przypadku musisz być przygotowany na testy - rozmowy techniczne. Egzamin ten nie jest łatwy i oprócz przygotowania moralnego potrzebne jest także przygotowanie techniczne. Niedawno natknąłem się na dużą listę pytań do wywiadu z programistą Java na dou. Pytania te są podzielone na różne poziomy - Junior, Middle i Senior. Nie przejmuj się: nie wszystkie pytania są łatwe, ale te oznaczone gwiazdką są rzadko zadawane. Pytania są dobre, ale chciałbym spróbować odpowiedzieć na większość z nich. Jasne, że nie będę się rozpisywał w ramach jednego artykułu, bo pytań jest w nim mnóstwo. Będzie to zatem cała seria artykułów odpowiadających na takie pytania. Od razu podkreślę kilka punktów:

1. Istnieje doskonały artykuł z najważniejszymi pytaniami i odpowiedziami na nie. Niektóre pytania pokrywają się z przedstawioną powyżej listą (250+), dlatego pytania te zostaną pominięte, aby nie powielać ponownie informacji.

2. Pytania są prezentowane w języku ukraińskim, ale ponieważ większość uczestników JavaRush to osoby rosyjskojęzyczne (w większym stopniu ja też), odpowiedzi będą po rosyjsku.

3. Odpowiedzi będą krótkie, ponieważ jeśli napiszesz bardzo szczegółowo, odpowiedzi na niektóre pytania mogą wymagać osobnego artykułu. A podczas rozmów kwalifikacyjnych nie są potrzebne tak szczegółowe i obszerne odpowiedzi, ponieważ Twój rozmówca ma tylko godzinę, aby przeprowadzić z Tobą wywiad na niezbędne tematy (i, jak pamiętasz, to wystarczy). Dla tych, którzy lubią kopać głębiej, zostawiam linki.

Zacznijmy więc.

Pytania i odpowiedzi na poziomie młodszym

Ogólne problemy

1. Jakie znasz wzorce projektowe? Opowiedz nam o dwóch szablonach, których użyłeś w swojej pracy.

Istnieje ogromna różnorodność szablonów: możesz zacząć się z nimi zapoznawać od tego i tego artykułu. Cóż, tym z Państwa, którzy chcą zapoznać się z nimi szczegółowo, polecam lekturę książki „Head First. Wzorce projektowe" . Za jego pomocą możesz w łatwy i szczegółowy sposób przestudiować najbardziej podstawowe wzorce projektowe. Jeśli chodzi o wzorce projektowe, które możesz wykorzystać jako przykłady podczas rozmowy kwalifikacyjnej, przychodzą Ci na myśl następujące:

• Builder to często używany szablon, alternatywa dla klasycznego tworzenia obiektów;
• Wzorzec strategii , który z natury reprezentuje polimorfizm. Oznacza to, że mamy jeden interfejs, ale zachowanie programu będzie się zmieniać w zależności od tego, jaka konkretna implementacja tego interfejsu została przeniesiona do funkcjonalności (teraz strategia jest praktycznie stosowana wszędzie w aplikacjach Java).

Jeśli to Ci nie wystarczy, zwróć uwagę na Springa (jeśli go już znasz), bo to cała platforma frameworków, które z kolei usiane są wzorcami od góry do dołu. Oto kilka przykładów tego, o czym mówię:

• Factory – w ApplicationContext (lub w BeanFactory);
• Singleton - domyślnie wszystkie komponenty bean są singletonami;
• Proxy - w zasadzie wszystko w Springu używa tego wzorca w taki czy inny sposób, na przykład AOP;
• Łańcuch odpowiedzialności to wzorzec oparty na koncepcji, na której działa Spring Security;
• Szablon - używany w Spring Jdbc.

Rdzeń Javy

2. Jakie typy danych są dostępne w Javie?

Java ma prymitywne typy danych:

• byte — liczby całkowite z zakresu -128 do 127, ważą 1 bajt;
• short — liczby całkowite z zakresu -32768 do 32767, ważą 2 bajty;
• int — liczby całkowite od -2147483648 do 2147483647, ważą 4 bajty;
• long — liczby całkowite z zakresu od 9223372036854775808 do 9223372036854775807, ważą 8 bajtów;
• float — liczby zmiennoprzecinkowe z zakresu -3,4E+38 do 3,4E+38, ważą 4 bajty;
• double — liczby zmiennoprzecinkowe z zakresu -1,7E+308 do 1,7E+308, ważą 8 bajtów;
• char — pojedyncze znaki w formacie UTF-16, ważą 2 bajty;
• wartość logiczna true/false , waży 1 bajt.

Oraz referencyjne typy danych , które wskazują obiekty na stercie.

3. Czym obiekt różni się od prymitywnych typów danych?

Pierwsza różnica: ilość zajmowanej pamięci: prymitywy zajmują bardzo mało, ponieważ zawierają tylko swoją własną wartość, podczas gdy obiekty mogą zawierać bardzo, bardzo wiele różnych wartości: zarówno prymitywy, jak i odniesienia do innych obiektów. Druga różnica: Java jest językiem obiektowym, więc wszystko w niej działa poprzez interakcję między obiektami, a prymitywy nie bardzo do siebie pasują (właściwie dlatego Java nie jest językiem w 100% obiektowym). Po trzecie, kontynuacja drugiego: ponieważ Java koncentruje się na interakcji między obiektami, obiekty te mają wiele różnych mechanizmów zarządzania nimi. Na przykład konstruktory, metody, wyjątki (które działają głównie na obiektach) itp. Właściwie, aby prymitywy mogły w jakiś sposób zaangażować się (pracować) w tym zorientowanym obiektowo środowisku, wynaleziono opakowania dla typów pierwotnych ( Integer , Character , Double , Boolean ...)

4. Jaka jest różnica między przekazywaniem parametrów przez referencję i przez wartość?

Pola pierwotne przechowują swoją wartość: na przykład, jeśli ustawimy int i = 9; pole i przechowuje wartość 9 . Kiedy mamy referencję do obiektu, oznacza to, że mamy pole z referencją do obiektu, czyli inaczej mówiąc, z wartością adresu obiektu w pamięci.

Cat cat = new Cat();

Okazuje się, że pola z referencją do obiektu przechowują także wartości , wartości adresów pamięci. Oznacza to, że cat przechowuje w pamięci wartość adresu nowego obiektu Cat() . Kiedy przekazujemy parametr do metody, jego wartość jest kopiowana. W przypadku prymitywu wartość prymitywu zostanie skopiowana. W związku z tym metoda będzie działać z kopią, której zmiana nie będzie miała wpływu na oryginał. W przypadku typu referencyjnego zostanie odpowiednio skopiowana wartość adresu pamięci, adres będzie taki sam jak obiekt, na który wskazuje. A jeśli zmienimy obiekt za pomocą tego nowego linku, zostanie on zamieniony na stary (w końcu oba wskazują na ten sam obiekt).

5. Co to jest JVM, JDK, JRE?

JVM - wirtualna maszyna Java to maszyna wirtualna, która uruchamia kod bajtowy Java wygenerowany wcześniej przez kompilator. JRE - Java Runtime Environment - to zasadniczo środowisko do uruchamiania aplikacji Java, które zawiera JVM , standardowe biblioteki i inne komponenty do uruchamiania apletów i aplikacji napisanych w języku programowania Java. Innymi słowy , środowisko JRE to pakiet wszystkiego, co jest potrzebne do uruchomienia skompilowanego programu w języku Java, ale nie zawiera narzędzi i programów użytkowych, takich jak kompilatory czy debugery do tworzenia aplikacji. JDK – Java Development Kit – rozszerzony zestaw JRE , czyli środowisko nie tylko do uruchamiania, ale także do tworzenia aplikacji Java. JDK zawiera wszystko, co znajduje się w środowisku JRE, a także różne dodatkowe narzędzia - kompilatory i debugery potrzebne do tworzenia aplikacji w Javie (zawiera także dokumentację Java).

6. Dlaczego warto używać JVM?

Jak wspomniano powyżej, wirtualna maszyna Java to maszyna wirtualna, która uruchamia kod bajtowy Java wygenerowany wcześniej przez kompilator. Oznacza to, że JVM nie rozumie kodu źródłowego Java. Dlatego w pierwszej kolejności kompilowane są pliki .java , które po kompilacji mają już rozszerzenie .class i które prezentowane są w postaci tego samego kodu bajtowego, który rozumie JVM. Każdy system operacyjny ma własną maszynę JVM, więc po otrzymaniu plików kodu bajtowego JVM wykonuje ją, dostosowując ją do systemu operacyjnego, w którym to się dzieje. Właściwie, ze względu na różne maszyny JVM, wersje JDK (lub JRE) różnią się dla różnych systemów operacyjnych (każdy z nich wymaga własnej maszyny JVM). Przypomnijmy sobie jak działa development w innych językach programowania. Tworzysz program, następnie jego kod jest kompilowany do kodu maszynowego dla konkretnego systemu operacyjnego i możesz go uruchomić. Innymi słowy, dla każdego systemu trzeba napisać różne wersje programu. Natomiast w Javie, dzięki podwójnemu przetwarzaniu kodu (kompilacja i przetwarzanie bajtów kodu JVM), możesz cieszyć się korzyściami płynącymi z wieloplatformowości. Raz stworzyliśmy kod, ponownie go skompilowaliśmy do kodu bajtowego, przenieśliśmy do dowolnego systemu operacyjnego, a lokalna maszyna JVM uruchamia kod. To legendarna właściwość języka Java — napisz raz, uruchom gdziekolwiek . Więcej na ten temat przeczytasz w artykule „ Kompilowanie i wykonywanie aplikacji Java od podstaw ”.

7. Co to jest kod bajtowy?

Jak powiedziałem powyżej, kompilator konwertuje kod Java na pośredni kod bajtowy (pliki z rozszerzeniem .java na pliki z rozszerzeniem .class). Kod bajtowy pod wieloma względami przypomina kod maszynowy, tyle że wykorzystuje zestaw instrukcji nie z prawdziwego procesora, ale z wirtualnego. Ponadto może zawierać sekcje skupiające się na wykorzystaniu kompilatora JIT, który optymalizuje wykonywanie poleceń dla rzeczywistego procesora, na którym uruchomiony jest program. Kompilacja JIT, zwana także kompilacją w locie, to technologia zwiększająca wydajność programu wykorzystującego kod bajtowy poprzez kompilowanie kodu bajtowego do komputera lub w innym formacie podczas działania programu. Jak można się domyślić, maszyna JVM używa kompilatora JIT podczas uruchamiania kodu bajtowego. Przyjrzyjmy się przykładowi kodu bajtowego: Niezbyt czytelny, prawda? Cóż, to nie jest instrukcja dla nas, ale dla JVM. Oto artykuł , który pomoże Ci lepiej zrozumieć to zagadnienie.

8. Jakie są cechy JavaBean?

JavaBeans to klasa Java z pewnymi regułami. Oto kilka zasad pisania JavaBean :

1. Klasa musi zawierać pusty (bez parametrów) konstruktor dostępu publicznego z modyfikatorem dostępu publicznego . Konstruktor ten umożliwia utworzenie obiektu tej klasy bez zbędnych problemów (aby nie było niepotrzebnego zamieszania z parametrami).

2. Dostęp do wewnętrznych pól klasy można uzyskać za pomocą metod get i set , co powinno być standardem. Na przykład, jeśli pole ma nazwę name , to getName i setName itp. To z kolei pozwala różnym narzędziom (frameworkom) na automatyczne określanie i aktualizację zawartości komponentów bean bez komplikacji.

3. Klasa musi zawierać przesłonięte wersje metod równości() hashCode() i toString() .

4. Klasa musi nadawać się do serializacji, czyli musi mieć interfejs znacznika - Serializable lub implementować interfejs Externalizable . Jest to konieczne, aby można było niezawodnie zapisać, przechowywać i przywrócić stan komponentu bean.

O rodzajach JavaBeans możesz przeczytać w tym materiale .

9. Co to jest błąd OutOfMemoryError?

OutOfMemoryError to jeden z krytycznych błędów wykonawczych związanych z działaniem wirtualnej maszyny Java (JVM). Wywoływane, gdy maszyna JVM nie może przydzielić obiektu, ponieważ nie ma dla niej wystarczającej ilości pamięci i moduł zbierający elementy bezużyteczne nie może przydzielić więcej pamięci. Niektóre typy OutOfMemoryError :

• OutOfMemoryError: Miejsce na stercie Java — nie można przydzielić obiektu na stercie Java z powodu niewystarczającej ilości pamięci. Błąd może być spowodowany wyciekiem pamięci lub tym, że domyślny rozmiar sterty nie jest wystarczająco duży dla bieżącej aplikacji.

• OutOfMemoryError: Przekroczono limit narzutu GC - w związku z tym, że ilość danych ledwo mieści się na stercie, śmieciarz działa cały czas, a program Java działa bardzo wolno i w efekcie przekroczony zostaje limit narzutu śmieciarza zostanie przekroczony i aplikacja ulegnie awarii z powodu tego błędu.

• OutOfMemoryError: Żądany rozmiar tablicy przekracza limit maszyny wirtualnej — wskazuje, że aplikacja próbowała przydzielić pamięć dla tablicy większej niż rozmiar sterty, co ponownie może być spowodowane niewystarczającą domyślną alokacją pamięci.

• OutOfMemoryError: Metaspace — na stercie zabrakło miejsca na metadane (metadane to instrukcje dotyczące klas i metod).

• OutOfMemoryError: żądaj bajtów rozmiaru żądania z powodu. Brak przestrzeni wymiany - wystąpił błąd podczas próby alokacji pamięci ze sterty, w wyniku czego na stercie zabrakło pamięci.

10. Co to jest ślad stosu? Jak to zdobyć?

Stack Trace to lista klas i metod, które zostały wywołane do tego momentu w aplikacji. Możesz wywołać funkcję śledzenia stosu w określonym punkcie aplikacji w następujący sposób:

StackTraceElement[] stackTraceElements =Thread.currentThread().getStackTrace();

W ten sposób otrzymamy tablicę elementów śladowych stosu ułożonych w kolejności LIFO - Last In First Out . W Javie z reguły, gdy mówią o śladzie stosu, mają na myśli ślad stosu, który jest wyświetlany w konsoli, gdy wystąpi błąd (lub wyjątek). Możesz uzyskać ślad stosu wyjątków w następujący sposób:

StackTraceElement[] stackTraceElements;
try{
                ...
} catch (Exception e) {
   stackTraceElements = e.getStackTrace();
}

Cóż, jeśli mówimy o wyświetlaniu w konsoli śladu stosu wyjątków:

try{
                ...
} catch (Exception e) {
  e.printStackTrace();
}

Ponadto, jeśli mamy błąd, niesprawdzony wyjątek lub sprawdzony wyjątek , którego nie przetworzymy, a jedynie przekażemy dalej, to w przypadku awarii aplikacji automatycznie otrzymamy w konsoli ślad stosu wyjątków. Mały przykład wyjątku śledzenia stosu w konsoli: Możesz przeczytać więcej o śledzeniu stosu tutaj . Dziś skupimy się na tym zagadnieniu...