Extensibilité de Java pour l’iSeries, 2ème partie

Quand de multiples threads peuvent
accéder simultanément à  des données
ou des variables partagées, il faut un
mécanisme capable de réduire ou
d’éliminer les problèmes de sécurité
des threads. La méthode la plus courante
pour cela est appelée synchronisation
(ou verrouillage).

La synchronisation n’est pas gratuite.
Quand on ajoute cette fonction à 
une application, la longueur du chemin
de traitement augmente. Pour
jouer la sécurité, il faut ajuster le code
de l’application de manière à  tenir
compte du traitement supplémentaire
qu’inflige l’ajout de cette fonction. Il
faut aussi éviter d’utiliser excessivement
le verrouillage d’application.

Les figures 1 et 2 montrent des
exemples de deux techniques de
verrouillage courantes : une méthode synchronisée et un bloc synchronisé
utilisant « this », respectivement.
Sachez que ces deux techniques verrouillent
le même objet – l’instance de
l’objet lui-même.

Une autre technique consiste à  utiliser
des objets de verrou de synchronisation
séparés (figure 3). Cette approche
peut présenter l’inconvénient
suivant : des objets de verrouillage séparés
peuvent être plus difficiles à  analyser
et à  déboguer parce que chaque
verrou est présenté simplement
comme un objet.

Le verrouillage peut aussi nuire à 
l’extensibilité. Quand vous ajoutez la
synchronisation à  votre application,
vous risquez (temporairement) d’empêcher
d’autres threads de s’exécuter
en les verrouillant d’une section particulière
du code applicatif. Pour des
sections de code synchronisées plus
vastes, le risque de verrouillage des
threads augmente. C’est un facteur important
quand on écrit des applications
« thread-safe ». Dans des environnements
où il n’y a pas de partage
intensif, toutes les techniques donnent
satisfaction. En revanche, quand le partage
s’effectue à  grande échelle, il est
important de limiter la synchronisation
à  une section de code relativement petite.
De petits blocs de code synchronisé
améliorent l’extensibilité et limitent
le verrouillage aux seuls blocs de
code qui en ont besoin.

Vous pouvez limiter la synchronisation
dans vos applications de plusieurs
manières. L’une d’elles consiste à  diviser
de grandes sections du code synchronisé
en verrouillages multiples.
Les figures 4 et 5 montrent des
exemples de code lourdement synchronisé
et le même code scindé en
verrouillages multiples, respectivement.

Il s’agit d’un exemple simple. Dans
des applications complexes, la mise en
place de multiples verrouillages plus
petits (plutôt que des blocs de
synchronisation plus grands) peut
améliorer sensiblement l’évolutivité
et réduire le temps d’attente du verrouillage. A noter que pour limiter
le risque d’impasses, les blocs synchronisés
doivent être acquis dans le même
ordre (chaque fois qu’ils sont acquis)
quand deux ou plus sont maintenus simultanément.

Une autre façon de limiter le verrouillage
consiste à  utiliser des objets
immuables, qui n’ont pas besoin de
synchronisation parce qu’on ne peut
pas les modifier sans créer un nouvel
objet. Cette technique risque d’augmenter
l’overhead en raison de la taille
des jeux de travail supplémentaires et
du ramasse-miettes nécessaire pour
nettoyer les objets non référencés.
Toutefois, en utilisant des objets immuables,
vous simplifierez votre
conception quand vous écrirez une application
hautement extensible ou évolutive.

Autre possibilité : la méthode
« share nothing ». Au lieu de construire
une application multithreaded, vous
pouvez exécuter des réplications multiples
de l’application dans des JVM
(Java Virtual Machines) indépendantes.
Cette façon de faire entraîne
beaucoup de duplication et la taille accrue du jeu de travail demandera davantage
de mémoire, mais on peut
ainsi éliminer pratiquement le verrouillage.
Cette technique convient
particulièrement aux applications qui
ne sont pas multithreaded de manière
inhérente ou qui n’ont pas un haut degré
de dépendance vis-à -vis de données
partagées.