Version imprimable
La société Soat, société d'ingénierie et de conseil en informatique vous propose un retour sur la session « 50 nouvelles choses que l'on peut faire avec Java 8 » présentée par José Paumard lors de la conférence Devoxx France 2014.
http://soat.developpez.com/tutoriels...-devoxxfr2014/
Vous pouvez profiter de ce message pour partager vos commentaires.
Mickael
la session est disponible sur parleys, comme toutes les sessions de devoxx france 2014
Je m'étais pas trop interessé jusque la a ce java 8.
J'avoue en voyant les exemple être bluffé par certains truc (notamment les ajout de collection) qui vont me permettre de me débarasser enfin des libraires que j'avais faites a la main (et qui avait le meme principe en plus bancale).
On a beaucoup parlé des expressions lambdas, mais les méthodes par défaut sont tout aussi importante à mon avis.Citation:
Envoyé par wax78
Cela permet de faire évoluer les APIs sans tout casser !
a++
Une très légère correction (mais qui m'a sauté aux yeux).
dans l'exemple des String il y a une erreur :
boolean b = list.removeIf(s -> s.length() > 4) ;
list.forEach(System.out::println); // affiche one, two, three
le commentaire devrait être :
// affiche one, two, four
car la longueur de "three" = 5
Cordialement,
Bonne idée d'avoir un aperçu des nouveautés de l'API. :P
Quelques corrections :
Étrange, je ne lis ça nulle part et vois que ConcurrentHashMap utilse toujours des blocs synchronized. Je pense qu'il s'agit d'une erreur, je suis curieux d'en connaître la source.Citation:
ConcurentHashMap a été complètement réécrite. Cette implémentation est thread-safe et n'utilise pas de lock.
Je suppose qu'il faut mettre Duration à la place de la virguleCitation:
, représente une durée entre deux instants.
... idem avec ZonedDateTimeCitation:
, permet la gestion des fuseaux horaires.
Bonjour à vous deux,
Merci pour le feedback. Je vais regarder cela à tête reposée. Si je vois qu'il est nécessaire de demander l'avis de l'auteur je verrai avec lui.
Mickael
Je ne sais pas si c'est nouveau, mais Oracle dit:Citation:
Envoyé par ymajoros
http://docs.oracle.com/javase/8/docs...ntHashMap.htmlCitation:
However, even though all operations are thread-safe, retrieval operations do not entail locking, and there is not any support for locking the entire table in a way that prevents all access.
Donc il y a bien du lock-free dans ConcurrentHashMap en Java 8.
Bonjour,
Je suis l'auteur de cet article concernant la conférence « 50 nouvelles choses que l'on peut faire avec Java 8 » de José Paumard.
Merci pour vos retours, ci-dessous quelques précisions concernant vos remarques.
@marc.guillemin: Tu as entièrement raison, il s'agit d'une erreur d'inattention de ma part.
Le résultat devrait afficher one, two, four.
@ymajoros: Je suis d'accord avec toi concernant les termes manquants : Duration et ZonedDateTime.
Etant présent sur ma version de l’article, il s'agit surement d'un oubli lors de la mise en page de celui-ci.
bredelet a répondu à ta question à propos de la ConcurrentHashMap.
Cordialement,
ConcurrentHashMap a toujours été lock-free, et ce depuis son introduction dans Java 5 : http://docs.oracle.com/javase/1.5.0/...ntHashMap.htmlCitation:
Envoyé par bredelet
Par contre elle a bien été réécrite pour Java 8, afin de profiter des améliorations apportées par les Streams et les lambdas.
Source : http://docs.oracle.com/javase/8/docs.../changes8.html
Citation:
New methods in java.util.concurrent.ConcurrentHashMap
The Collections Framework has undergone a major revision in Java 8 to add aggregate operations based on the newly added streams facility and lambda expressions. As a result, the ConcurrentHashMap class introduces over 30 new methods in this release. These include various forEach methods (forEach, forEachKey, forEachValue, and forEachEntry), search methods (search, searchKeys, searchValues, and searchEntries) and a large number of reduction methods (reduce, reduceToDouble, reduceToLong etc.)
Other miscellaneous methods (mappingCount and newKeySet) have been added as well. As a result of the JDK 8 changes, ConcurrentHashMaps (and classes built from them) are now more useful as caches. These changes include methods to compute values for keys when they are not present, plus improved support for scanning (and possibly evicting) entries, as well as better support for maps with large numbers of elements.
a++
Tutoriel Java court mais intéressant. Par contre je m'attendais à trouver 50 points, il n'y en a que 8, un titre un peu voleur dommage ;)
@CodeZ-Julien
Merci pour ton intervention. Je prends note et je vais modifier l'article en conséquence
Mickael
Pour
C'est corrigéCitation:
@marc.guillemin: Tu as entièrement raison, il s'agit d'une erreur d'inattention de ma part.
Le résultat devrait afficher one, two, four.
@ymajoros: Je suis d'accord avec toi concernant les termes manquants : Duration et ZonedDateTime.
Etant présent sur ma version de l’article, il s'agit surement d'un oubli lors de la mise en page de celui-ci.
Mickael
Citation:
Envoyé par CodeZ-Julien
Citation:
Envoyé par bredelet
Globalement, les opérations de lecture ne bloquent pas et l'écriture bloque le moins possible. Ce n'est pas exactement "lock-free", et ça n'a pas été réécrit depuis Java 5.Citation:
Envoyé par adiGuba
Pour une implémentation sans lock aucun : ConcurrentSkipListMap fait exactement ça et est là depuis un moment (1.6). Classe très intéressante, par ailleurs.
Je lis toujours dans l'article :
Je suggère de corriger ce paragraphe.Citation:
ConcurentHashMap a été complètement réécrite. Cette implémentation est thread-safe et n'utilise pas de lock.
On parlait bien du lock-free sur les accès en lecture ("retrieval operations do not entail locking").Citation:
Envoyé par ymajoros
Elle a bien été réécrite dans Java 8. Il suffit de jeter un coup d'oeil au source :Citation:
Envoyé par ymajoros
Source JDK7 : http://hg.openjdk.java.net/jdk7/jdk7...ntHashMap.java
Source JDK8 : http://hg.openjdk.java.net/jdk8/jdk8...ntHashMap.java
a++
Moi aussi, justement. Pour revenir sur le sujet, ma réaction concerne cette partie de l'article original :Citation:
Envoyé par adiGuba
Il est vrai que beaucoup semble avoir été réécrit. Par contre, qu'elle soit thread-safe est évident (ben c'est le but), et elle utilise bien des locks en écriture.Citation:
ConcurentHashMap a été complètement réécrite. Cette implémentation est thread-safe et n'utilise pas de lock.
Effectivement, en comparant les sources, je vois que beaucoup de choses ont changé.
Et donc, l'article reste comme ça ?Citation:
Cette implémentation est thread-safe et n'utilise pas de lock.
Bonjour ymajoros,
Suite à tes différents échanges sur ce billet, j'ai réalisé une petite analyse de la nouvelle classe ConcurrentHashMap.
On est tous bien d'accord qu'il n'y a pas de lock sur les opérations lecture.
Concernant les opérations d'écriture, c'est un peu plus compliqué.
Contrairement à la classe ConcurrentHashMap V7, l'implémentation V8 n'est plus découpée en segments (16 par défaut je crois). Ces segments impliquaient des locks sur une partie de la ConcurrentHashMap lors de l'insertion d'un élément dans un de ces segments. La déclaration de ces segments est conservée dans cette nouvelle implémentation pour des raisons de compatibilité concernant la sérialisation - voir le commentaire dans le code source
For serialization compatibility. Null unless serialized; see below
La nouvelle implémentation a une structure différente pour stocker les valeurs. Elles sont stockées dans une table de type Node. Un Node est composé d'un hash, de la clé, de la valeur et de l'élément suivant. Le hash correspond à une valeur calculée à partir du hashCode de la clé. Pour des raisons de performance, il est très fortement conseillé d'utiliser des objets immutables pour la clé. Ce calcul du hashCode de la clé permet d'insérer les données de manière repartie sur la table des Nodes et d'éviter au maximum les collisions entre les différentes clés.
Dans les cas ou il y a une collision entre le calcul du hash de deux clés, les deux valeurs sont insérées dans le même Node et on en déduit que ce Node est finalement une liste chainée. Les éléments avec des hash identiques sont insérés les uns après les autres dans cette liste chainée. L'insertion du premier élément dans le Node n'utilise pas de lock et par extension de lock sur la ConcurrentHashMap. L'insertion des éléments suivants utilise un lock sur le premier élément du Node et donc il n'y a pas de lock sur les autres Node de la table. Cette explication concerne seulement l'opération put.
Tu as raison, cette implémentation utilise des locks sur certaines opérations. La structure interne permet de réduire le nombre de locks (et son impact sur le nombre de données verrouillé) que la ConcurrentHashMap V7. Cette nouvelle implémentation offre de bien meilleur performance sur les opérations concurrentes.
Juste une petite remarque lorsqu’il y a beaucoup trop de collisions, la table des Nodes est étendue. Je ne sais pas s’il a un lock complet sur l’ensemble des données de la ConcurrentHashMap.
@Mickael Baron. Une petite correction de cet article est nécessaire pour lever toute ambigüité et mauvaise interprétation.
@ymajoros. Merci pour ta contribution. J'espère que mes explications étaient assez claires.
Julien.
Intéressant, merci pour ton analyse. Si la clé n'est pas immuable, où perd-on du temps ?Citation:
Envoyé par CodeZ-Julien
Ce n'est pas une raison de performance : si la clef n'est pas immuable on risque de ne plus pouvoir accéder à sa valeur.Citation:
Envoyé par bredelet
:arrow: Les données sont stockés selon le hashCode de la clef.
Si tu modifies la valeur de la clef après l'avoir inséré, son hashCode ne correspondra plus et tu ne pourra plus accéder à la valeur via get().
Ce n'est pas spécifique à la ConcurrentHashMap mais commun à la majorité des Map qui ont quasi toute le même mécanisme basé sur le hashCode...
a++