tag:blogger.com,1999:blog-8405107760807432973.post2434464383084411603..comments2024-01-04T09:55:32.459-08:00Comments on Java Concurrency (&c): Immutability in JavaJeremy Mansonhttp://www.blogger.com/profile/04241094734813086257noreply@blogger.comBlogger25125tag:blogger.com,1999:blog-8405107760807432973.post-43173199351624402152020-03-24T19:47:16.091-07:002020-03-24T19:47:16.091-07:00Not really. Final field guarantees are about ensur...Not really. Final field guarantees are about ensuring you won't see a partially constructed view of the object, not about ensuring you will see the most up to date reference.<br /><br />For example, there used to be a string implementation with an offset, length, and array field. You could have code like this:<br /><br /><br />String s1 = "/usr/tmp"; <br />String s2 = s1.substring(Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-64905942976963669832020-03-24T03:55:30.906-07:002020-03-24T03:55:30.906-07:00If we still need some synchronization to ensure sa...If we still need some synchronization to ensure safe publication of the reference to the ImmutableHashMap instance, Is the semantics of final about correct initialization redundant indeed? Anonymoushttps://www.blogger.com/profile/07403990732452416005noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-32578400810578712512020-03-18T21:05:33.073-07:002020-03-18T21:05:33.073-07:00Could you explain more about this aspect of immuta...<i>Could you explain more about this aspect of immutability? Thanks.</i><br /><br />I did a series of posts on immutability in 2008:<br /><br />https://jeremymanson.blogspot.com/2008/04/immutability-in-java.html<br />https://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-2.html<br />https://jeremymanson.blogspot.com/2008/07/immutability-in-java-part-3.html<br /><br />LMK if you don&#Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-5004044540784167502020-03-18T21:03:22.367-07:002020-03-18T21:03:22.367-07:00So final is mainly for post construction immutabil...<i>So final is mainly for post construction immutability, and its usage for correctly construction can be replaced by volatile. Is my understanding correct?</i><br /><br />It depends a bit on the actual code, but that's the general idea.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-15149534911242889252020-03-17T20:38:35.364-07:002020-03-17T20:38:35.364-07:00is transitively reachable from a final field
Coul...<i>is transitively reachable from a final field</i><br /><br />Could you explain more about this aspect of immutability? Thanks.Anonymoushttps://www.blogger.com/profile/07403990732452416005noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-63390829863742788722020-03-17T20:33:48.401-07:002020-03-17T20:33:48.401-07:00You can. With objects a) that are never mutated an...<i>You can. With objects a) that are never mutated and b) for which all of their fields are final, the only real danger is that the reference to the object itself doesn't get updated properly. You might have the situation, for example, where you see a null when you read the reference to the object, but another thread has already constructed an instance.<br /><br />For a String, this is rarelyAnonymoushttps://www.blogger.com/profile/07403990732452416005noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-38195361337422861732017-04-02T23:05:10.225-07:002017-04-02T23:05:10.225-07:00@Gabrieaj - Not sure what that means to be thread ...@Gabrieaj - Not sure what that means to be thread safe? Are you asking if it is immutable, and if the correctly constructed values are guaranteed to be seen if accessed by another thread? No, it isn't, per all of the discussion in the post and in the comments. Make it immutable.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-67077831529065877042016-10-28T16:12:03.364-07:002016-10-28T16:12:03.364-07:00You can. With objects a) that are never mutated a...You can. With objects a) that are never mutated and b) for which all of their fields are final, the only real danger is that the reference to the object itself doesn't get updated properly. You might have the situation, for example, where you see a null when you read the reference to the object, but another thread has already constructed an instance.<br /><br />For a String, this is rarely Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-45151540476265878022016-10-28T01:55:49.143-07:002016-10-28T01:55:49.143-07:00Sorry Jeremy,
one more question to clarify. You s...Sorry Jeremy,<br /><br />one more question to clarify. You say "without using any additional synchronization"...<br />But we still have to use volatile or some other mechanism for publishing a reference to ImmutableHashMap object, right?damluarhttps://www.blogger.com/profile/05425803973033514785noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-48744657237677610202016-10-27T07:32:41.089-07:002016-10-27T07:32:41.089-07:00From the point of view of the memory model, you ne...From the point of view of the memory model, you need to enforce that in your program, yeah. But I expect most data treated as immutable in a given program is already not mutated. :)Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-28400732670600132612016-10-27T02:36:03.544-07:002016-10-27T02:36:03.544-07:00Hello Jeremy,
so effectively some objects are co...Hello Jeremy, <br /><br />so effectively some objects are considered immutable by JVM even though they are strictly speaking mutable.<br /><br />In this case JVM guarantees safe publishing, but doesn't guarantee visibility of changes made afterwards.<br /><br />To make such objects really immutable, we need to add another rule that their observable state never changes.<br /><br />Do I damluarhttps://www.blogger.com/profile/05425803973033514785noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-17572522600895818242010-06-13T11:06:20.865-07:002010-06-13T11:06:20.865-07:00@anonymous - This implementation is incorrect. Ea...@anonymous - This implementation is incorrect. Each thread has to do explicit synchronization to be guaranteed to see the correctly constructed object. However, some threads may only read m_unsafeFlag, which does no synchronization.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-54637891761112652092010-06-04T11:47:58.889-07:002010-06-04T11:47:58.889-07:00We have situation where multiple thread would like...We have situation where multiple thread would like to get a reference and if it is null then the thread would create one. But there should only be one instance created and shared by all the threads. We can use AtomicReference for that an do something like this.<br /><br />final AtomicReference globalRef = new AtomicReference(); // This instance is accessible to all the threads.<br /><br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-90006807708720114482009-02-04T23:08:00.000-08:002009-02-04T23:08:00.000-08:00@gary -- you should check out the rest of the post...@gary -- you should check out the rest of the posts I made on this topic. I deal with that particular issue in this post: http://jeremymanson.blogspot.com/2008/12/benign-data-races-in-java.htmlJeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-60395892351647130892009-02-04T10:50:00.000-08:002009-02-04T10:50:00.000-08:00I think that the definition of immutable needs rev...I think that the definition of immutable needs reviewing. String for example is often used as an example of an Immutable object, yet it's state does indeed change post contsruction. <BR/><BR/>Checkout the hashcode() method for String which lazily evaluates the hash field on first call. So technically the state of the instance changes on the first call to hashcode().<BR/><BR/>The real question Gary Frosthttps://www.blogger.com/profile/12935992295051239076noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-36606139535994393802008-08-27T00:16:00.000-07:002008-08-27T00:16:00.000-07:00A small fix: o.x, not o.f.Correct. Sorry about th...<I>A small fix: o.x, not o.f.</I><BR/><BR/>Correct. Sorry about that.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-2635728282432374472008-08-26T23:09:00.000-07:002008-08-26T23:09:00.000-07:00A small fix: o.x, not o.f.A small fix: o.<I>x</I>, not o.<I>f</I>.Jonathanhttps://www.blogger.com/profile/01422208177256569696noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-79640455013430929202008-05-26T23:01:00.000-07:002008-05-26T23:01:00.000-07:00I don't see how "final" makes a difference threat-...<I>I don't see how "final" makes a difference threat-safety-wise. You'll always get an exception if u try to change the internal state. "final" keyword only prevents u to change the reference of the internal map of the first example, so it is a precaution mechanism for programmers. As for the Collections.unmodifiable, imho, it adheres the first approach because that does not dictates a specific Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-38482846649225226792008-05-26T08:00:00.000-07:002008-05-26T08:00:00.000-07:00I don't see how "final" makes a difference threat-...I don't see how "final" makes a difference threat-safety-wise. You'll always get an exception if u try to change the internal state. "final" keyword only prevents u to change the reference of the internal map of the first example, so it is a precaution mechanism for programmers. As for the Collections.unmodifiable, imho, it adheres the first approach because that does not dictates a specific Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-68590218991505022412008-05-24T11:03:00.000-07:002008-05-24T11:03:00.000-07:00It's probably also worth noting that not all final...<I>It's probably also worth noting that not all final variables can be changed. The compilier may decide to inline your final "static" primitive or Strings for you. In this case, you won't be able to change the value.<BR/>Why does java allow you to change final variables via reflection? It's a nice feature, but in principle, shouldn't this always be disallowed?</I><BR/><BR/>Actually, it is worse Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-68403691496469321622008-05-23T13:38:00.000-07:002008-05-23T13:38:00.000-07:00It's probably also worth noting that not all final...It's probably also worth noting that not all final variables can be changed. The compilier may decide to inline your final "static" primitive or Strings for you. In this case, you won't be able to change the value. <BR/>Why does java allow you to change final variables via reflection? It's a nice feature, but in principle, shouldn't this always be disallowed?Dannyhttps://www.blogger.com/profile/13354553266166547455noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-77170660012130535822008-04-27T11:31:00.000-07:002008-04-27T11:31:00.000-07:00If you are worried about changing the original you...<I>If you are worried about changing the original you can take a copy like.<BR/><BR/>unmodifiableMap(new HashMap(map))<BR/><BR/>The original an be change safely.</I><BR/><BR/>That's if you are worried about changing the mappings, not the actual keys and values. My point was that unmodifiableMap doesn't make a copy of the keys and values of the map, it just delegates to a newly constructed Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-49433948055439294352008-04-27T01:53:00.000-07:002008-04-27T01:53:00.000-07:00If you are worried about changing the original you...If you are worried about changing the original you can take a copy like.<BR/><BR/>unmodifiableMap(new HashMap(map))<BR/><BR/>The original an be change safely.<BR/><BR/>Its worth noting that final variable can have their contents changes, and final variables can be changed using reflection.Peter Lawreyhttps://www.blogger.com/profile/17982030676088168612noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-15823922712911735802008-04-26T10:49:00.000-07:002008-04-26T10:49:00.000-07:00That's such an important point, and it was so stup...That's such an important point, and it was so stupid that I forgot it, that I put it in the text. Collections.unmodifiableBlah() uses the delegation model.Jeremy Mansonhttps://www.blogger.com/profile/04241094734813086257noreply@blogger.comtag:blogger.com,1999:blog-8405107760807432973.post-66916674361391527612008-04-26T03:13:00.000-07:002008-04-26T03:13:00.000-07:00Can the collections returned byjava.util.Collectio...Can the collections returned by<BR/>java.util.Collections.unmodifiable...()<BR/>be considered immutable provided the underlying collection is never updated after its wrapping?Anonymousnoreply@blogger.com