Instance variable in Java Spring Bean

Question

I'm developing a Java Spring MVC project and i hesitate using instance variable in Java Spring Bean.I want to ask some question about this subject.

I used a instance variable in my Java Spring Bean and its type is String.

private String abc = "hell";

As we know , Java Spring default scope is Singleton and they are constructed at the startup time of the project. .It is single instance and my instance variable must be thread-safe.

I used this variable "abc" in the methods of the beans and when they are reached by multiple threads will it damage the consistency of data each thread?

For an example , Thread 1 reach the bean and take the abc variable changed it as "hello".On that time , Thread 1 reference to abc variable point "hell" or "hello"? I'm confused at this topic.

I make the String abc variable to ThreadLocal object to provide each thread holds their own abc variable.But i have read that using ThreadLocal objects occurs memory leakage in the Tomcat.After 7.0 version of Tomcat it is said that it is fixed.

Because each thread holds their own variable, and when their job is finished they return the thread pool which is managed by container.But,returning the pool , ThreadLocal object is not destroyed and they cause memory leakage.

Moreover, String object is immutable so in theorical view does it cause the multi-threaded problem ??

is each thread holds their String variable on its own? For example, Thread 1 triggers and then start the method invocation , and create seperate String variable "abc" and Thread 2 triggers then it creates new String variable "abc" and do they damage "abc" variable each other?

I really wonder this concept of usage and eager to learn the answers.

Solution 1

I will try to address your questions separately.

I used this variable abc in the methods of the beans and when they are reached by multiple threads will it damage the consistency of data each thread?

The short answer to this question is yes. If you wrote a different value for abc in one Thread it may or may not be seen from another thread. This is the reason the volatile keyword was introduced.

I you want to have mutable singleton beans in Spring then you need be careful with synchronization and use of volatile.

The data will not be "corrupted" because, as you point out, String is immutable. But one thread may not see that another has changed the value of abc.

So you have a variable abc;

1. abc = "Hi."
2. thread 1 reads abc as "Hi.".
3. thread 1 changes abc by writing to the reference: abc="Hello."
4. thread 2 reads abc, it is unclear whether abc reads "Hi." or "Hello.".

I make the String abc variable to ThreadLocal object to provide each thread holds their own abc variable

ThreadLocal is used to have each thread be given a different instance of a variable. This is often used to tying state to a thread in a web server as web servers use a thread pre request model.

Tomcat 7 does not fix ThreadLocal leak issues. If you do not remove the variable you have set from a thread then it will cause a leak. Or even worse a request will get items from the context of another request. This happens when a thread is checked into the pool with context left in its ThreadLocal and then is checked out by another request.

Tomcat 7 tires to detect these issues and swap out threads to drop their ThreadLocal variables. This is expensive and can be avoided by using ThreadLocal properly.

You need to clear ThreadLocal variables in a servlet filter.

So:

If you have a variable abc that you want to write to in one thread and for that change not to been seen in other threads then you can use a ThreadLocal, but you need to be very careful to clear state after each request.

If you have a variable abc that yo want to write to in one thread and for that change to be seen in other threads then you can use a singleton bean with a volatile variable.

Solution 2

I guess in your case if you define the scope of your bean which has your instance variables as Singleton that should do.

As per Spring reference document, below is the definition for Singleton scoped bean.

To put it another way, when you define a bean definition and it is scoped as a singleton, 
the Spring IoC container creates exactly one instance of the object defined by that bean 
definition. This single instance is stored in a cache of such singleton beans, and all 
subsequent requests and references for that named bean return the cached object.

Singleton is the Default scope that your bean will be put into if you don't specify.

Also, below statement should be kept in mind, if you try to handle your case using Spring's bean scope approach.

This approach is powerful and flexible in that you can choose the scope of the objects  
you create through configuration instead of having to bake in the scope of an object at    
the Java class level.