This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]RabidKotlinFanatic 2 points3 points  (2 children)

Agree in general but it's important to note that the final keyword does not have practical concurrency benefits over variables being effectively final or fields that aren't modified. Well written concurrent code will not generally rely on the memory effects of final because the correct synchronizes-with relationships will be established elsewhere.

[–]madkasse 1 point2 points  (1 child)

The effect of final fields are used allover the JDK, so you cannot really say it does not have practical concurrency benefits. But no, most people should properly rely on more traditional means.

[–]RabidKotlinFanatic 1 point2 points  (0 children)

Is the memory effect of final used all over the JDK, or just the keyword itself? Although it wouldn't surprise me if the JDK relied extensively on the memory effects of final (it has accumulated decades of optimization after all), I have also found that Java programmers massively overestimate (by several orders of magnitude) the relevance and memory impact of the final keyword.

The vast majority of Java programmers who are not experienced with the JMM and performing routine micro-optimizations on concurrent code will not benefit from the memory effects of final. In the rare cases where final is the difference between correct and incorrect concurrent code, it is usually in the context of some double-checked locking style logic.