CODEWITHSUNDEEP
javamultithreadingspring-boot
ITWorker
ITWorker

Reputation: 995

Is the following date formatting code thread safe?

I have read in several places that SimpleDateFormat is not thread-safe, but threading is a concept that is still unclear to me, so I wanted to know if the following code is thread safe;

static public java.util.Date stringToDate(String strDate, String pattern)
            throws ParseException {
        if (strDate == null || strDate.trim().equals("")) {
            return null;
        } else {
            SimpleDateFormat sdf = new SimpleDateFormat(pattern);
            return new java.util.Date(sdf.parse(strDate).getTime());
        }
    }

This is a method that resides in a class called "DateUtils.java" and in the Spring Boot application I am working on, I access it using DateUtils.stringToDate... wherever I need to convert a String to a date (or pass up the exception to the controller if the conversion fails).

Since this method is using a new instance of SimpleDateFormat each time the method is called, I am going with the belief that it is thread-safe, but I am posting this question here to be corrected if I am wrong. The main reason I am not 100% sure is that even though it is a new instance in each method call, the instance of the DateUtils class (which I believe is not even an instance since it was not even initialized to begin with, please correct me if I am wrong here too) is shared during application runtime.

Thank you.

Upvotes: 0

Views: 286

Answers (2)

Kedar Mhaswade
Kedar Mhaswade

Reputation: 4695

This method is thread-safe because it implements the thread safety using stack confinement. None of the variables are shared by more than one thread since in Java every thread gets its own stack. The formal arguments (String) being immutable is also necessary for the thread safety of this method.

Upvotes: 1

hagrawal7777
hagrawal7777

Reputation: 14688

Short answer is that what you are doing is absolutely thread safe because:

  • You are not doing any mutation to global state.
  • You are working with all local variables
  • Your method accepts String as input which is immutable
  • In the end you are returning "mutable" Date object but you are using "defensive copying".

Since this method is using a new instance of SimpleDateFormat each time the method is called, I am going with the belief that it is thread-safe, but I am posting this question here to be corrected if I am wrong.

Yes, you are right in your understanding, however some more word of wisdom is that even that could lead to concurrency issue if you are returning that object back or if that object, in some way, accessible outside of that method to other threads, because in that case object of SimpleDateFormat could be mutated.

The main reason I am not 100% sure is that even though it is a new instance in each method call, the instance of the DateUtils class (which I believe is not even an instance since it was not even initialized to begin with, please correct me if I am wrong here too) is shared during application runtime.

You method stringToDate is static which basically means that to access this method you do not need any object of DateUtils, this doesn't cause any concurrency/thread safety issues until you:

  • You are accessing global state and doing any mutation to global state without any synchronization
  • Your accepts mutable objects as method parameters, and do not use "defensive copying" before working on them
  • In the end you return a "mutable" object without "defensive copying".

Upvotes: 2

Related Questions