[Java] nieuwe concurrency functonaliteit jdk 5.0

[Alarmnummer]

Ik ben de afgelopen tijd weer veel bezig met allerlei threading problematiek en ik maak hiervoor met veel plezier gebruik van de concurrency library van Doug Lea. Ik gebruik op dit moment een backport van 1.5 naar 1.4, zodat ik het onder 1.4 ook kan gebruiken en daarin dezelfde functionaliteit aantref als 1.5 (alleen andere package naam).

Een van de dingen waar ik het meeste gebruik van maak is de threadpool functionaliteit (ExecutorServices) en daarmee is het een eitje om allerlei pooling problematiek op te lossen. Verder zit er nog een heel reeks met andere componenten in die imho nooit hadden mogen ontbreken zoals Semaforen, mutexen etc etc.

De hele library is verder goed doordacht maar toch eenvoudig te gebruiken en uit te breiden. Voor een threadpool had ik meer behoefte controle over de prioriteiten van de threads. Gelukkig kan je een eigen implementatie aanmaken van de ThreadFactory -> dus daar een nieuwe implementatie van gemaakt waar ik deze controle wel had en meteen beter naamgeving van de threads/threadgroup. Prachtig.

Verder is threading problematiek lastig om te testen. en om in ieder geval de basis dingen te kunnen testen, wissel ik de ThreadPoolExecutorService om met een DirectExecutorService waarin geen threadpool zit, maar tasks worden afgehandeld door de thread die de tasks er ook in plaatst -> prachtig.

Ik ben dus erg tevreden met deze library. Goed doordacht, eenvoudig te gebruiken (als je thuis bent in concurrency control), en goed uit te breiden. Wie werkt er nog meer graag met de nieuwe concurrency library?

[edit]
Een ander belangrijk minpunt dat eindelijk is opgelost, is het Collection Framework ook eindelijk eens een Queue heeft (en er zitten bij de concurrency control library een hele reeks met implementaties)

[edit2]
Url backport toegevoegd.

[ Voor 21% gewijzigd door Alarmnummer op 18-04-2005 11:38 ]

[raoulduke]

Ik ben bezig met een in Java geschreven port-proxy en daarin gebruik ik ook ingebouwde thread pools. Het scheelt me een hoop werk, omdat ik anders zelf al deze classes had moeten namaken. Het verbaasde me eigenlijk wel dat er in de J2SE5 API zoveel extra functionaliteit zit omtrent concurrency, het maakt het programmeren van multi-threaded applicaties veel sneller en betrouwbaarder.

Daarnaast maak ik, waar nodig, nu ook gebruik van de AtomicInteger klasse, dat maakt de code een stuk leesbaarder en je bespaart er een hoop synchronized-statements mee.

Alarmnummer, jij vertelde over een backport van deze klassen naar 1.4, kan je misschien een linkje van geven, want ik zou hier graag mee willen experimenteren, vooral omdat Mac OS X nog geen 1.5 ondersteuning heeft.

[Alarmnummer]

De backport

[edit]
Wat ik trouwens ook erg handig vind is dat je bij het submitten van een taak bij een ExecutorService, ook een Future terug kunt krijgen, waarmee je bij een (eventuele) asynchrone call toch op een synchrone manier ermee kunt werken.

[ Voor 60% gewijzigd door Alarmnummer op 18-04-2005 16:55 ]

[Alarmnummer]

Verder niemand into the new concurrency library? Doen jullie niet aan threading?

[Nick_S]

Alarmnummer schreef op dinsdag 19 april 2005 @ 10:58:
Verder niemand into the new concurrency library? Doen jullie niet aan threading?

Op dit moment inderdaad weinig. Ben thuis bezig met spring, hibernate en gewoon netjes leren programmeren (PMD vind ik wel een mooie plugin, ook jUnit probeer ik mezelf aan te leren om standaard te gebruiken)

Voor mijn werk ben ik nu bezig met Tibco en hiervoor hoeft ook weinig threading te gebeuren.

[Alarmnummer]

Je kunt het trouwens ook perfect combineren met Spring:

XML:

    <bean id="indexUpdaterExecutorService"
        class="edu.emory.mathcs.util.concurrent.ThreadPoolExecutor"
        destroy-method="shutdown">

        <!-- core pool size -->
        <constructor-arg index="0">
            <value>5</value>
        </constructor-arg>

        <!-- max pool size -->
        <constructor-arg index="1">
            <value>10</value>
        </constructor-arg>

        <!-- die-time -->
        <constructor-arg index="2">
            <value>5000</value>
        </constructor-arg>

        <!-- de tijdeenheid waarmee deze executorservice gaat werken -->
        <constructor-arg index="3">
            <ref bean="edu.emory.mathcs.util.concurrent.TimeUnit.MILLISECONDS"/>
        </constructor-arg>

        <!-- de queue die gebruikt wordt om taken in op te slaan -->
        <constructor-arg index="4">
            <bean class="edu.emory.mathcs.util.concurrent.LinkedBlockingQueue">
                <constructor-arg index="0">
                    <!-- maximale size -->
                    <value>5000</value>
                </constructor-arg>
            </bean>
        </constructor-arg>

        <!--
            - de threadfactory die deze executorservice gebruikt om de threads aan te laten maken
            -->
        <constructor-arg index="5">
            <bean class="com.jph.concurrency.StdThreadFactory">
                <constructor-arg index="0">
                    <!--
                        - Geef de analyzers een lage priority zodat het systeem voor
                        - gebruikers wel vlot blijft aanvoelen. Zorg er verder voor
                        - dat de prioriteit lager is dan die van de indexwriters, zodat
                        - je eerder een index weg gaat schrijven, dan analyze taken
                        - gaat uitvoeren.
                        -->
                    <value>2</value>
                </constructor-arg>

                <!-- De naam van ThreadGroup waar de Threads onder vallen -->
                <constructor-arg index="1">
                    <value>analyzers</value>
                </constructor-arg>
            </bean>
        </constructor-arg>
    </bean>

[ Voor 35% gewijzigd door Alarmnummer op 19-04-2005 11:15 ]

[jAnO!]

Ik ben van plan om in mijn SCJD opdracht iig gebruik te gaan maken van de nieuwe concurrencymogelijkheden, ook het nieuwe lockingmechanisme staat mij zeer aan.

Maar dan moet ik er wel aan toe komen ;-( Is nogal veel werk.
Toch maar eerst SCWCD doen.