Why String objects are immutable?

Asked

Viewed 1,208 times

11

Up to the latest stable version, Java 8, type objects String are immutable. That is, any change in a String causes the creation of a new object String.

This is not harmful from a performance point of view?

What was the motivation for objects String are immutable? Or, in a more general line, what is the primary intention in making an immutable object?

java string oop

  • There are good answers on the Soen, and a look http://stackoverflow.com/questions/22397861/why-is-string-immutable-in-java

  • Thanks to String being immutable, JVM can maintain a single instance of a given String and share it with other places that use this same value. This can result in a memory saving.

1 answer

10


This will never change, a lot of code has been done with this premise. It could one day have something additional, in a way it already has that is the StringBuilder.

In a general way it is not harmful in performance so that it is worth being different. Java, like some other languages, does not aim to have the best possible performance but the most suitable performance for most situations. Surely lose at some things and win at others.

Competition

One reason to be so is the competition. It is very difficult to deal with mutable objects when access can be done on threads different. Today this is very important. Treat access to string Concurrent mode changeable is bad from the performance point of view because it requires locking. That alone already has a cost. And worse, this cost can be paid even if you’re not doing anything concurrent. It’s done "just in case". You can even optimize it, but it’s very complicated.

Protecting

Imagine you are given a file name to open, then the file name is changed by another thread and then the operation that was valid is no longer. What is the solution? You would have to stop the string throughout the operation. Only there may be other parts of the code that need to manipulate this string You can’t do anything anymore, you have to wait. You can release it soon, or take hours, days, it’s not viable. What’s the solution? Copy the content, so you have a new object. But you may have copied something that will not even be changed by another thread. So the copy made was a wastage. In most cases this is what happens.

Strings Mutables play the responsibility of protecting the text for anyone who reads it. Most of the time this protection is not necessary, but you pay the price anyway, because there is no way to know when it will be necessary or not, except in extremely simple code, which is not the case of language libraries. These copies never know if there may be a competition problem or not.

Protection in the right place

Strings immutable put the cost of protecting the text to anyone who changes its value. Writing occurs very little in a code. It is better to pay this price.

If you know you have a case that will make several changes use the StringBuilder and then convert to String (related). That’s a string changeable and not made for indiscriminate use, should be used at a specific point and never shared between threads.

Hashing

It hinders or even prevents its use as keys to structures such as HashMap. If the code hash of string easy mute, need to reorganize the Buckets of the structure at all times.

Other reasons

  • Strings are more insecure (improper access)
  • Make caching difficult
  • And the reuse of (interning for Flyweight)
  • In addition to compile-time optimizations
  • Reflection gets much more complicated.

Browser other questions tagged java string oop

You are not signed in. Login or sign up in order to post.