6 Replies Latest reply: Jun 18, 2011 12:07 PM by 796440 RSS

    Because String objects are immutable they can be shared.?

    866541
      Below is the line written under javadocs of String class .

      "Because String objects are immutable they can be shared."

      Link is http://download.oracle.com/javase/6/docs/api/java/lang/String.html

      Yes String are immutable but still it does not gaurantee that their wont be any thread interference in case of string. Say if we have string object as instance variable i.e str1
      Two threads enter concurrently tries to modify the str1. we are not sure what will be the final value of str1 . wondering what does the statement mean when it is saying "they can be shared."?
        • 1. Re: Because String objects are immutable they can be shared.?
          802316
          So you can conclude that a String can be shared, but a mutable, non-volatile reference to a String cannot be safely shared.

          If a reference to an immutable, is immutable it can be safely shared. If the reference is volatile and doesn't need to be used in combination with another field, it can be safely shared.

          Edited by: Peter Lawrey on Jun 17, 2011 3:21 PM
          • 2. Re: Because String objects are immutable they can be shared.?
            796440
            JavaFunda wrote:
            Below is the line written under javadocs of String class .

            "Because String objects are immutable they can be shared."

            Link is http://download.oracle.com/javase/6/docs/api/java/lang/String.html

            Yes String are immutable but still it does not gaurantee that their wont be any thread interference in case of string.
            Yes, it does.

            A String object's state cannot be changed. So multiple threads can share the same String object. No thread can change it, so there's no need to worry about another thread seeing the change, since the change cannot exist.
            Say if we have string object as instance variable i.e str1
            Two threads enter concurrently tries to modify the str1. we are not sure what will be the final value of str1 . wondering what does the statement mean when it is saying "they can be shared."?
            You're talking about changing the value of a reference variable that points to a String object. That's completely different. It's not what that quote is talking about.

            Make sure you understand the difference between a reference and the object it refers to.
            • 3. Re: Because String objects are immutable they can be shared.?
              836548
              Hi,

              Refer the below link:

              http://www.javapractices.com/topic/TopicAction.do?Id=29

              Strings are thread-safe and have no synchorization issues.
              When u say about modifying the string, it does'nt mean the earlier value is been overridden with the new one, but it means the string instance variable is been assigned with the new String object reference.
              • 4. Re: Because String objects are immutable they can be shared.?
                796440
                833545 wrote:
                Hi,

                Refer the below link:

                http://www.javapractices.com/topic/TopicAction.do?Id=29
                No. That link is irrelevant. If it contradicts the facts I have already pointed out to you, it is wrong.

                >
                Strings are thread-safe and have no synchorization issues.
                When u say about modifying the string, it does'nt mean the earlier value is been overridden with the new one, but it means the string instance variable is been assigned with the new String object reference.
                Wrong. Don't try to tell me what I meant when I said something.

                When somebody talks about Strings being threadsafe because they are immutable, they're talking about the fact that a String object's state cannot change after creation. They are not talking about reference variables that point to String objects. If your link says otherwise, it is very confused.

                ANY reference variable--String or otherwise--can be changed if it is not declared final. It is not interesting or sensible to talk about "immutable" reference variables. What is interesting and meaningful in this context is an object's state. As already explained, a String's state cannot change, and therefore, it is threadsafe.
                • 5. Re: Because String objects are immutable they can be shared.?
                  836548
                  No. That link is irrelevant. If it contradicts the facts I have already pointed out to you, it is wrong.
                  i think you have not gone through the link.

                  >
                  Wrong. Don't try to tell me what I meant when I said something.
                  I was not trying to tell you anything,the reply was for :op
                  • 6. Re: Because String objects are immutable they can be shared.?
                    796440
                    833545 wrote:
                    No. That link is irrelevant. If it contradicts the facts I have already pointed out to you, it is wrong.
                    i think you have not gone through the link.
                    I don't need to. I'm not the one who is confused.
                    =================================
                    EDIT: Okay, I skimmed it. It seems correct. I thought you were saying that it contradicts something I said earlier, but it does not. I misunderstood what point you were trying to make. I didn't realize you were agreeing with me. Sorry for the misunderstanding.
                    =================================

                    Immutable objects like String, Integer, Double, etc. are safe for use by multiple threads because their contents cannot change.

                    A completely separate issue is the reference variables that point to these immutable objects--or to any object, whether mutable or immutable. If the reference variable is not final, then, depending on your requirements, you may need to synchronize all access to it if it is to be used in a multithreaded context. However, this is NOT what the original quote is talking about. The OP seems unclear on the distinction between the value of a reference and the state of the object the reference points to.

                    Edited by: jverd on Jun 18, 2011 10:07 AM