title: Does re-putting an object into a ConcurrentHashMap cause a "happens-before" memory relation?
body: <p>I'm working with <em>existing</em> code that has an object store in the form of a ConcurrentHashMap. Within the map are stored mutable objects, use by multiple threads. No two threads try to modify an object at once by design. My concern is regarding the visibility of the modifications between the threads.</p>
  
  <p>Currently the objects' code has synchronization on the "setters" (guarded by the object itself). There is no synchronization on the "getters" nor are the members volatile. This, to me, would mean that visibility is not guaranteed. However, when an object is modified it is <strong>re-put</strong> back into the map (the <code>put()</code> method is called again, same key). Does this mean that when another thread pulls the object out of the map, it will see the modifications?</p>
  
  <p>I've researched this here on stackoverflow, in <a href="http://jcip.net/" rel="nofollow noreferrer">JCIP</a>, and in the package description for java.util.concurrent. I've basically confused myself I think... but the final straw that caused me to ask this question was from the package description, it states:</p>
  
  <blockquote>
    <p>Actions in a thread prior to placing an object into any concurrent collection happen-before actions subsequent to the access or removal of that element from the collection in another thread. </p>
  </blockquote>
  
  <p>In relation to my question, do "actions" include the modifications to the objects stored in the map before the re-put()? If all this does result in visibility across threads, is this an efficient approach? I'm relatively new to threads and would appreciate your comments.</p>
  
  <p><strong>Edit:</strong></p>
  
  <p>Thank you all for you responses! This was my first question on StackOverflow and it has been very helpful to me.</p>
  
  <p>I have to go with <a href="https://stackoverflow.com/users/134894/ptomli">ptomli</a>'s answer because I think it most clearly addressed my confusion. To wit, establishing a "happens-before" relation doesn't necessarily affect modification visibility in this case. My "title question" is poorly constructed regarding my actual question described in the text. <a href="https://stackoverflow.com/users/134894/ptomli">ptomli</a>'s answer now jives with what I read in <a href="http://jcip.net/" rel="nofollow noreferrer">JCIP</a>: "To ensure all threads see the most up-to-date values of shared mutable variables, the reading and writing threads must synchronize on a common lock" (page 37). Re-putting the object back into the map doesn't provide this common lock for the modification to the inserted object's members.</p>
  
  <p>I appreciate all the tips for change (immutable objects, etc), and I wholeheartedly concur. But for this case, as I mentioned there is no concurrent modification because of careful thread handling. One thread modifies an object, and another thread later reads the object (with the CHM being the object conveyer). I think the CHM is insufficient to ensure that the later executing thread will see the modifications from the first given the situation I provided. However, I think many of you <em>correctly answered the title question</em>.</p>