Wątek w Javie przechodzi przez zdefiniowane stany (enum Thread.State). Opisując proces, wymień stany, przejścia i metody, które je wywołują.
| Stan | Znaczenie | Jak się tu trafia |
|---|---|---|
| NEW | Wątek utworzony, jeszcze nie uruchomiony | new Thread(...) |
| RUNNABLE | Gotowy do wykonania lub wykonywany (Java nie rozróżnia „ready" i „running") | start() |
| BLOCKED | Czeka na wejście do sekcji synchronized (na monitor) | monitor zajęty przez inny wątek |
| WAITING | Czeka bezterminowo na inny wątek | wait(), join() bez czasu |
| TIMED_WAITING | Czeka przez określony czas | sleep(t), wait(t), join(t) |
| TERMINATED | Zakończony (run() się zakończył lub wyjątek) | koniec metody run() |
start() na wątku TERMINATED rzuca IllegalThreadStateException; wątek nie wraca z TERMINATED. Java łączy „gotowy" i „aktywny" w jeden stan RUNNABLE (o przydziale procesora decyduje planista SO).Thread i nadpisanie run().Runnable (run() zwraca void, bez wyniku) i przekazanie do new Thread(runnable) — preferowane (kompozycja).Callable<T> (call() zwraca wynik i może rzucać wyjątki) — uruchamiana przez ExecutorService, wynik przez Future.start() — uruchamia NOWY wątek (a run() wywołane wprost działa w bieżącym wątku).join() — bieżący wątek czeka, aż dany wątek się zakończy.sleep(ms) — usypia wątek (nie zwalnia monitorów).interrupt() — ustawia flagę przerwania; wątek powinien ją sprawdzać/obsłużyć.wait()/notify()/notifyAll() — synchronizacja na monitorze (tylko w synchronized); wait() zwalnia monitor. Warunek sprawdzaj w pętli while.synchronized, volatile tylko widoczność, AtomicInteger, blokady). Obiekty niemutowalne są bezpieczne z natury. value++ nie jest atomowe.Źródło zdarzenia (komponent) utrzymuje listę słuchaczy (obserwatorów). Gdy zajdzie zdarzenie (np. klik), tworzy obiekt zdarzenia (ActionEvent) i wywołuje metodę każdego zarejestrowanego słuchacza (actionPerformed). To wzorzec Observer. W Swing zdarzenia obsługiwane są na EDT.
launch() → JavaFX tworzy wątek aplikacji → init() (poza wątkiem FX) → start(Stage) (na wątku FX, budujemy Scene i pokazujemy Stage) → działanie (pętla zdarzeń) → stop() przy zamknięciu.
Obiekt jest kandydatem do usunięcia, gdy nie jest już osiągalny z żadnego korzenia (referencji lokalnej, statycznej itp.). GC działa automatycznie; nie należy polegać na finalize().
MVC (Model–View–Controller) rozdziela odpowiedzialności, żeby dane, prezentacja i logika sterowania były niezależne.
Zalety: separacja odpowiedzialności, łatwiejsze testowanie, jeden model może mieć wiele widoków.
Swing stosuje wariant MVC zwany model–delegat: View i Controller są połączone w jeden „UI delegate", a osobno stoi model danych.
| Komponent | Model danych |
|---|---|
JTable | TableModel / AbstractTableModel |
JList | ListModel |
JTree | TreeModel |
JComboBox | ComboBoxModel |
Model przechowuje dane, a komponent tylko je wyświetla. Po zmianie danych model musi powiadomić widok (wzorzec Observer), np. fireTableRowsInserted(...) — inaczej tabela się nie odświeży.
Do implementacji AbstractTableModel nadpisujemy min. getRowCount(), getColumnCount(), getValueAt(r,c); opcjonalnie isCellEditable, setValueAt.
fire...).JavaFX opiera prezentację na właściwościach obserwowalnych (Property) i wiązaniach (bindings), co naturalnie realizuje ideę MVVM (Model–View–ViewModel).
StringProperty, IntegerProperty) — obserwowalna wartość; można podpiąć ChangeListener.etykieta.textProperty().bind(model.imieProperty()). Po związaniu nie można ustawiać ręcznie bez unbind().TableView/ListView odświeża widok automatycznie (bez ręcznego „fire" jak w Swing).ViewModel wystawia dane modelu jako właściwości; widok (FXML + kontroler) wiąże się z nimi. Zmiana modelu automatycznie odświeża widok i odwrotnie — bez pisania kodu synchronizującego.
fire...); JavaFX — automatyczne przez właściwości/wiązania i ObservableList. To częsty punkt różnicujący.