Les microbenchmark sont juste la pour avoir des exemples de code très concis et obtenir des chiffres facilement pour valider le problème. Ils ne reflètent pas du tout la réalité et ne cherche pas à simuler un problème du monde réel en particulier.
Je suis aussi d'accord que @Contended peut faire potentiellement plus de mal que de bien surtout si des couillons comme moi commence à l'expliquer, ce qui implique qu'il va être abusé dans tous les sens. En pratique 99% des developpeurs ne devraient jamais avoir à y toucher, et pour les autres c'est un usage exceptionnel. Si je vois ca dans du code business je pars en courant de même que si une brique d'infra l'utilise à plus de 1, 2, 5 fois.
Pour ceux qui veulent un exemple plus concret issu du monde réel, LMAX avait très bien documenté le problème sur un ring buffer utilisé pour structure d'échange de donnée entre threads ou typiquement les variable head and tail vont se retrouver sur la même ligne de cache alors qu'elles sont massivement utilisées par des threads différents. Ca se voit par ce que la structure est méchamment optimisée pour ne jamais avoir de lock et une seule barrière mémoire.
Donc oui dans la vraie vie, si tu ne travailles pas sur ce genre de strucuture n'utilise pas @Contented.
[^] # Re: attention au microbenchmark
Posté par ckyl . En réponse au journal OpenJDK 8, JEP 142 & False Sharing. Évalué à 7.
Je suis totalement d'accord avec toi.
Les microbenchmark sont juste la pour avoir des exemples de code très concis et obtenir des chiffres facilement pour valider le problème. Ils ne reflètent pas du tout la réalité et ne cherche pas à simuler un problème du monde réel en particulier.
Je suis aussi d'accord que @Contended peut faire potentiellement plus de mal que de bien surtout si des couillons comme moi commence à l'expliquer, ce qui implique qu'il va être abusé dans tous les sens. En pratique 99% des developpeurs ne devraient jamais avoir à y toucher, et pour les autres c'est un usage exceptionnel. Si je vois ca dans du code business je pars en courant de même que si une brique d'infra l'utilise à plus de 1, 2, 5 fois.
Pour ceux qui veulent un exemple plus concret issu du monde réel, LMAX avait très bien documenté le problème sur un ring buffer utilisé pour structure d'échange de donnée entre threads ou typiquement les variable
headandtailvont se retrouver sur la même ligne de cache alors qu'elles sont massivement utilisées par des threads différents. Ca se voit par ce que la structure est méchamment optimisée pour ne jamais avoir de lock et une seule barrière mémoire.Donc oui dans la vraie vie, si tu ne travailles pas sur ce genre de strucuture n'utilise pas @Contented.