GsonインスタンスをモデルBeanの静的フィールドとして使用しても問題ありませんか（再利用）。

これが私が実装したモデルです：

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);
    }
}

すべてのLoginSessionインスタンスに対して新しいGsonインスタンスを作成することは役に立たないと思いました。

しかし、私が心配しているのは、スレッドの安全性の問題です。約1000以上のインスタンス/秒が作成されます。

Gsonインスタンスを静的フィールドとして使用しても問題ありませんか？

アドバイス/修正をありがとう。

私には問題ないようです。GSONインスタンスには、の特定のインスタンスに関連するLoginSessionものはないため、静的である必要があります。

GSONインスタンスはスレッドセーフである必要があり、それに関するバグが修正されました。

コアGsonクラスはスレッドセーフです。GSONで発生したと思われるスレッドセーフの問題が発生しました。この問題は、カスタムJsonDeserializerを使用しJsonSerializerてDate解析およびフォーマットするときに発生しました。結局のところ、スレッドセーフの問題は、私のメソッドSimpleDateFormatがスレッドセーフではない静的インスタンスを使用することでした。静的SimpleDateFormatをThreadLocalインスタンスでラップすると、すべてがうまくいきました。

コメントによると、既存の単体テストは実際にはあまりテストしていません。スレッドセーフティに関連するものには注意してください...

スレッドの安全性をチェックする単体テストがあります。

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

この単体テストは、考えられるすべてのマシン構成で考えられるすべての問題を見つけるのに十分かどうか疑問に思われるかもしれません。これについてのコメント？

ドキュメントにもこの文があります：

Gsonインスタンスは、Json操作を呼び出している間、状態を維持しません。そのため、複数のJsonシリアル化および逆シリアル化操作で同じオブジェクトを自由に再利用できます。

しばらく前にスレッドセーフティの問題があり、ApacheコモンズでFastDateFormatを使用して解決しました。

Gsonインスタンスを再利用できるかどうか疑問に思う人々を助けるために、この周りにGistの gist リンクを作成したところです。セッターはなく、すべての変数はプライベートです。

したがって、SimpleDateFormatの問題以外は、他の場所で状態を維持することはありません。

ぜひチェックしてみてください。これはこれらの1つに返信するのは初めてです。一度だけお返しさせていただきます。:)