L'état d'un objet est simplement l'ensemble des valeurs prises par toute ou partie des différents champs qui le composent. Il peut arriver que la valeur de certains champs puisse être définie par la valeurs d'autres champs. Stocker cette valeur déduite permet d'éviter d'avoir à la calculer à nouveau à chaque demande, ce mécanisme est une sorte de cache : on cache le résultat d'un calcul dans un champ, dont on sait que sa valeur ne changera que si l'un des champs qui participe à ce calcul voit sa valeur changer. La valeur de certains champs peut aussi dépendre d'objets en relation de cet objet. L'état d'un objet peut-il changer au fil de l'exécution de l'application ? On ne peut que répondre au cas par cas à cette question. Si la classe de cet objet est immutable , la réponse est non. Certains de ces champs peuvent avoir une valeur fixée une fois pour toute à la construction de l'objet. Ces objets ne peuvent donc pas changer d'état au cours de l'application. C'est le cas de la classe String, comme nous l'avons déjà vu. La protection de l'état d'un objet est l'un des enjeux de la programmation concurrente, au centre de la notion de thead-safety .

L'une des plus grandes difficultés de la programmation concurrente, est de maintenir l'état de nos objets cohérent, même lorsque plusieurs fils d'exécution les partagent. Prenons un exemple simple, qui illustre le fonctionnement de cette notion d'état. Considérons un immeuble, composé de vingt appartements. Cet immeuble possède une unique chaudière, qui permet de chauffer l'ensemble de ces appartements. Chaque appartement est muni d'un thermostat, qui permet aux occupants de cet appartement de demander une température plus chaude à la chaudière. Pour éviter de transformer notre immeuble en étuve, chaque thermostat est équipé d'une sécurité, qui empêche de trop augmenter la température. Nous pouvons modéliser ce problème avec deux classes : Commençons par écrire notre classe Chaudiere.
Écrivons à présent notre classe Thermostat.
Le fonctionnement de la classe Thermostat est simple. Une instance de cette classe est construite sur une instance de Chaudiere. Une unique méthode est exposée, qui demande l'augmentation de la température à la chaudière. Si la température de la chaudière est inférieure à 25°, alors cette augmentation est acceptée et la méthode plusChaud() retourne true, sinon cette méthode retourne false. Faisons à présent fonctionner notre système dans une méthode main(). Chaque habitant d'un appartement est un thread , qui possède un thermostat.
Heureusement que notre chaudière possède une sécurité, car nos vingt habitants demandent en tout 100 montées de température. On utilise dans ce code la méthode join() de la classe Thread, qui peut jeter une exception de type InterruptedException. Cette méthode a pour but d'attendre l'arrêt de l'exécution de ce thread . Elle rend la main quand ce thread a fini de s'exécuter. On pourra tenter d'exécuter ce code plusieurs fois. Et on a toutes les chances de constater que la température finale de notre chaudière est bien supérieure aux 25° auxquels on pourrait s'attendre ! Même si l'on met la ligne Thread.yield() en commentaires, on peut observer, plus rarement, des températures de 26° et plus. Comment cela est-il possible ?

Plusieurs principes et bonnes pratiques ont en fait été violés dans cet exemple, volontairement et à titre d'exemple. Comment la température de notre chaudière a-t-elle pu passer au-dessus de la limite que nous avons imposée ? Examinons le morceau de code qui pose problème.
Le problème se trouve dans ce code, entre le moment où l'on teste la valeur de la température, et le moment ou l'on demande son augmentation. Rappelons que c'est la machine Java qui décide quel thread peut s'exécuter à un instant donné. Elle a également la responsabilité de veiller à ce que chaque thread puisse s'exécuter à son tour, et à partager équitablement les ressources disponibles. Son rôle est donc aussi d'interrompre les threads en exécution, momentanément, pour passer la main à ceux qui sont attente. C'est ce qui se passe ici, au plus mauvais moment. Supposons que notre température soit de 24°. Un premier thread T1 exécute le test de température. Ce test répond true, T1 entre donc dans le bloc d'appel à l'augmentation de température. Avant que cette incrémentation ait pu avoir lieu, la machine Java suspend l'exécution de T1, et passe la main à T2. Cet autre thread effectue le test de température, qui répond toujours true. Le thread T2 entre donc dans le bloc, et va pouvoir augmenter la température. Mais avant qu'il puisse le faire, la machine Java l'interrompt encore, et passe la main à T3, qui va pouvoir, lui aussi, entrer dans le bloc d'augmentation de la température. Au bout d'un moment, la machine Java va rendre la main à T1, puis T2, puis T3. Chacun de ces threads va augmenter la température, puisqu'il a déjà passé le test. À l'issue de cette exécution, la température sera de 27°. Si l'on poursuit l'analyse un peu plus loin, on se rend compte qu'il existe un autre point sur lequel la machine Java peut interrompre l'exécution de nos threads . Il se trouve entre la lecture du champ temperature et son incrémentation. Pour cette explication, nous nous sommes placé dans le cas où tous les threads sont exécutés sur le même processeur. Sur une machine multiprocesseurs (ou multicœurs, ce qui revient au même), la réalité est un peu plus complexe, du fait que le champ temperature n'est pas volatile.

Il n'y a qu'une seule solution à ce problème : empêcher qu'un thread T2 puisse entrer dans le bloc de test et d'augmentation de la température si un thread T1 s'y trouve déjà. On peut parler ici d' atomicité : on souhaite que les deux opérations : ne soient pas séparables, qu'elles ne puissent s'exécuter qu'en une seule fois. La solution générale proposée par Java pour résoudre ce problème consiste à utiliser la notion de verrou . Il existe plusieurs manières d'utiliser un verrou en Java. Voyons ici la première, et la plus simple, elle consiste à synchroniser la méthode plusChaud().
Avec cette classe corrigée, notre problème d'augmentation de la température au-delà de la limite n'est plus observé. Cette façon de synchroniser l'accès à l'augmentation de la température permet de régler notre problème. Cela dit, on peut mieux faire, comme nous le verrons dans la suite.

On peut déclarer un champ volatile en Java. Mais ne nous égarons pas, cela ne signifie pas, comme on peut l'entendre parfois, que ce champ est un poulet. Ce mot-clé ne peut se poser que sur un champ, on ne peut pas déclarer une méthode comme étant volatile. Afin de comprendre son utilité, analysons le fonctionnement de deux threads qui partagent le même champ. Supposons que ces deux threads T1 et T2 soient en train de s'exécuter au même moment, sur deux processeurs différents, ou deux cœurs différents d'un même processeur. Cette situation était peut-être rare il y a quelques années, mais avec le temps, elle devient de plus en plus fréquente. Si l'on n'y prend pas garde, et si l'on ne fait rien pour l'empêcher, chacun de nos deux threads peut choisir de copier la valeur de ce champ localement à son processeur, par exemple dans un registre. De cette façon, les accès à la valeur de ce champ seront beaucoup plus rapides. Montrons le problème que cela peut poser. Supposons que T1 fixe une valeur pour ce champ. Dans le contexte que l'on vient de décrire, cette valeur est écrite dans un registre du processeur qui exécute T1, que T2 n'a aucune chance de voir. Il en va de même pour T2, qui peut modifier ce champ, sans que T1 puisse en être informé. T1 et T2 peuvent donc être dans une situation où, au même moment, ils voient chacun une valeur différente pour ce champ, alors qu'il devrait s'agir de la même en permanence. Une solution à ce problème est de synchroniser les blocs dans lesquels le champ en question est modifié. Effectivement, lorsqu'un thread sort d'un bloc synchronisé, alors toutes les variables qu'il a modifiées sont automatiquement publiées auprès de tous les autres threads qui les lisent. Ce comportement fait partie de la sémantique de fonctionnement de la synchronisation. Cette solution est valide, mais coûteuse. Le caractère volatile d'un champ apporte une autre solution, plus légère. Un champ déclaré volatile ne se comporte pas comme un champ normal. Toute écriture sur un de ces champs est appelée lecture volatile , et toute écriture est une écriture volatile . La règle est que toute lecture volatile d'un champ retourne la valeur fixée par la dernière écriture volatile qui a eu lieu sur ce champ. Cette règle s'applique systématiquement, indépendamment du thread dans lequel cette lecture ou cette écriture à eu lieu. En déclarant un champ volatile, on a donc la garantie que la valeur de ce champ, vue de n'importe quel thread est toujours à jour. L'intérêt est que l'accès à un champ volatile n'est pas synchronisé, et donc plus performant que l'accès à un champ qui se ferait au travers d'un bloc synchronisé. Dans la pratique, déclarer un champ volatile fait que la machine Java ne stockera pas ce champ dans un registre, ce qui rendra les lectures de ce champ légèrement moins performantes. Notons deux erreurs qu'il faut éviter de commettre : On dit que la synchronisation garantit à la fois l'atomicité et la visibilité, alors que la volatilité ne garantit que la visibilité.