Is it OK to use Gson instance as a static field in a model bean (reuse)?

JavaStaticThread SafetyGson

Java Problem Overview


Here's the model I implemented:

public class LoginSession {
    private static final Gson gson = new Gson();

    private String id;
    private String name;
    private long timestamp;

    public LoginSession(String id, String name) {
        this.id = id;
        this.name = name;
        this.timestamp = System.currentTimeMillis();
    }

    public String toJson() {
        return gson.toJson(this);
    }

    public static LoginSession fromJson(String json) {
        checkArgument(!isNullOrEmpty(json));
        return gson.fromJson(json, LoginSession.class);
    }
}

I thought it's useless to create new Gson instance for every LoginSession instance.

But what I'm worried about is thread-safety issues. Approximately 1000+ instances/sec will be created.

Is it OK to use Gson instance as static field?

Thanks for any advices/corrections.

Java Solutions


Solution 1 - Java

It seems just fine to me. There is nothing in the GSON instance that makes it related to a specific instance of LoginSession, so it should be static.

GSON instances should be thread-safe, and there was a bug regarding that which was fixed.

Solution 2 - Java

The core Gson class is thread-safe. I just encountered a thread-safety issue that was supposedly with GSON. The issue happened when using a custom JsonDeserializer and JsonSerializer for Date parsing and formatting. As it turned out, the thread-safety issue was with my method's use of a static SimpleDateFormat instance which is not thread-safe. Once I wrapped the static SimpleDateFormat in a ThreadLocal instance, everything worked out fine.

Solution 3 - Java

According to the comments the existing unit test does not really test much, be careful with anything related to thread safety...

There is a unit test checking for thread safety:

/**
 * Tests for ensuring Gson thread-safety.
 *
 * @author Inderjeet Singh
 * @author Joel Leitch
 */
public class ConcurrencyTest extends TestCase {
  private Gson gson;
  ...

You may wonder if this unit test is sufficient to find every possible problem on every possible machine configuration ? Any comments on this ?

There is also this sentence in the docs:

> The Gson instance does not maintain any state while invoking Json > operations. So, you are free to reuse the same object for multiple > Json serialization and deserialization operations.

Solution 4 - Java

We had issues with thread safety a while back and we solved it by using the FastDateFormat in apache commons.

Just created a gist Link for Gist around this to help the people wondering if Gson instances can be reused. They do not have setters and all vars are private.

So other than the SimpleDateFormat issue I don't see them maintaining state anywhere else.

Do check it out. This is my first time replying to one of these . Happy to give back for once . :)

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionphilipjkimView Question on Stackoverflow
Solution 1 - JavaMByDView Answer on Stackoverflow
Solution 2 - JavaentpnerdView Answer on Stackoverflow
Solution 3 - JavaChristophe RoussyView Answer on Stackoverflow
Solution 4 - JavaaarengeeView Answer on Stackoverflow