15 sierpnia 2012

Króciutko o j.u.concurrent.DelayQueue

Kolejny raz potwierdza się zasada, że kto czyta, nie błądzi. W przypadku pakietu java.util.concurrent możnaby powiedzieć, że jest to najbardziej nieprzestrzegana zasada, której hołduję od jakiegoś czasu i zamiast przysiąść nad dokumentacją javadoc, pozwalam sobie na poznawanie jej wyłącznie przy okazji i to w tak niewielkich dawkach, że byłoby grzechem nazwać je wykraczającymi przyzwoite minimum.

Na szczęście przyszło mi recenzować nadchodzącą książkę o java.util.concurrent - Java 7 Concurrency Cookbook z wydawnictwa Packt, więc chciał, czy nie chciał, jestem zaangażowany i poznaję.

Mojemu Maksymowi stuknęło 10 miesięcy! Postępy jakie robi we własnym rozwoju często są niezwykle zaskakujące i chciałbym móc to samo powiedzieć o swoim w kontekście j.u.concurrent. Przez ostatni miesiąc nauczył się sprawnie raczkować, siadać, wstawać, a nawet zaczyna chodzić asekurowany, czy to meblami czy przez inną osobę. Zaczyna mówić i od kilku dni daje się słyszeć blablabla, mama, czy inne dźwięki, których opisanie uważam za niemożliwe. Rozumie frazy: biedronka, nie, wypluj smoka, gdzie...?, lampa, daj, chodź, piciu piciu, am, otwórz buźkę i jeszcze kilka innych. Zaczęliśmy go przyzwyczajać do mycia zębów, bo przy 4 zębach i kolejnych 4 wychodzących, nie daje nam innego wyboru. Jada chętnie, dużo pije i ogólnie cacy. Oby tak dalej! A mówią, że nic nie trwa wiecznie :(

Gdyby przełożyć jego rozwój na mój w kontekście j.u.concurrent, to ja dopiero zacząłem raczkować. Pora to zmienić, bo za moment, to nie ja jego, ale on mnie będzie wychowywał. A jak Wam idzie poznawanie nowego API? Korzystacie z niego regularnie czy tylko z doskoku i to w ramach własnych, prywatnych projektów?

Na zakończenie krótki przykład z klasą, o istnieniu której dowiedziałem się właśnie z książki. Oto, proszę Państwa, wchodzi java.util.concurrent.DelayQueue. Trzeba było widzieć moją minę, kiedy przeczytałem o tej klasie, a nigdy wcześniej nawet słowa o niej nie czytałem. Niedobrze z moją znajomością Javki.

Pytanie kontrolne: Co będzie wypisane na ekran po uruchomieniu poniższej klaski?

package pl.japila.java7;

import java.util.concurrent.DelayQueue;
import java.util.concurrent.Delayed;
import java.util.concurrent.TimeUnit;

public class DelayQueueMain {

    static class Conference implements Delayed {

        long delay;

        public Conference(long delay) {
            this.delay = delay;
        }

        @Override
        public int compareTo(Delayed o) {
            Conference c = (Conference) o;
            return this.getDelay() < c.getDelay() ? -1 : this.getDelay() == c.getDelay() ? 0 : 1;
        }

        @Override
        public long getDelay(TimeUnit unit) {
            return delay;
        }

        public long getDelay() {
            return delay;
        }

    }

    public static void main(String[] args) {
        DelayQueue<Conference> conferences = new DelayQueue<Conference>();
        conferences.add(new Conference(5));
        conferences.add(new Conference(10));
        conferences.add(new Conference(15));

        System.out.println("Head (delay expired furthest in the past) element: " + conferences.poll());
    }

}

2 komentarze:

  1. W Twoim przykładzie obiekty nigdy nie opuszczą kolekcji bo ich opóźnienie jest stałe i zawsze dodatnie. Zobacz ten przykład - po upływie zadanego czasu (np. po 5 sekundach) obiekt wypada z kolekcji.

    Pętla kontynuuje do momentu, aż kolekcja jest pusta (po 15 sekundach). Taki przykład wydaje mi się lepiej ilustrować typowy przypadek użycia tej dość ciekawej klasy.

    OdpowiedzUsuń
  2. Pełna zgoda. Mój był do bani (choć wolałbym nazwać go "podchwytliwym"). Właśnie chodziło, aby pokazać, że mimo elementów w kolejce, poll() zwróci null. Pewnie wielu poległoby na egzaminie.

    Znałeś odpowiedź bez zaglądania do javadoc? Szczere gratulacje. To nie pierwszy raz, kiedy pozytywnie zaskakujesz mnie znajomością j.u.concurrent. Szacun!

    OdpowiedzUsuń