Ist es in Ordnung, die Gson-Instanz als statisches Feld in einer Model-Bean zu verwenden (Wiederverwendung)?
Lesezeit: 4 Minuten
philippim
Hier ist das Modell, das ich implementiert habe:
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);
}
}
Ich dachte, es ist sinnlos, für jede LoginSession-Instanz eine neue Gson-Instanz zu erstellen.
Aber was mir Sorgen macht, sind Thread-Sicherheitsprobleme. Es werden ungefähr 1000+ Instanzen/Sek. erstellt.
Ist es in Ordnung, die Gson-Instanz als statisches Feld zu verwenden?
Danke für eventuelle Hinweise/Korrekturen.
MByD
Es scheint mir einfach gut zu sein. Es gibt nichts in der GSON-Instanz, das sie mit einer bestimmten Instanz von in Verbindung bringt LoginSessionalso sollte es statisch sein.
@slott, wie bündelt/wiederverwendet ihr Gson-Instanzen? Instanziieren Sie jedes Mal, wenn Sie serialisieren müssen? Oder verwenden Sie einen threadlokalen Pool?
– Dilum Ranatunga
29. Oktober 2013 um 19:19 Uhr
Wir verwenden GSON zusammen mit Google Volley und wenn wir JSON-Daten gleichzeitig parsen, sehen wir dieses Problem. Soweit ich sehen kann, hängt dies mit der Tatsache zusammen, dass wir einen Zeitstempel zum Analysieren von Datetime-Werten definieren.
– Schlitz
30. Oktober 2013 um 13:15 Uhr
Datetime ist nicht threadsicher, das kann die Ursache sein, nicht dass GSON nicht threadsicher ist.
– Andreas Mattisson
29. November 2016 um 10:55 Uhr
entpnerd
Der Kern Gson Klasse ist Thread-sicher. Ich bin gerade auf ein Thread-Sicherheitsproblem gestoßen, das angeblich bei GSON aufgetreten ist. Das Problem trat bei der Verwendung einer benutzerdefinierten Datei auf JsonDeserializer und JsonSerializer zum Date analysieren und formatieren. Wie sich herausstellte, lag das Problem mit der Thread-Sicherheit in der Verwendung einer Statik in meiner Methode SimpleDateFormat Instanz, die nicht Thread-sicher ist. Sobald ich die Statik eingewickelt habe SimpleDateFormat in einem ThreadLocal Beispiel, alles hat gut geklappt.
Ich habe Gson und SimpleDateFormat verwendet und Threadfehler auf Gson.fromJson erhalten. Es stellte sich heraus, dass die Klasse, in die ich konvertierte, eine nicht-threadsichere HashMap hatte. Ich habe es auf ConcurrentHashMap umgestellt und alles funktioniert perfekt.
– Gregory Alan Bolcer
31. Dezember 2020 um 20:22 Uhr
Christoph Roussy
Laut den Kommentaren testet der vorhandene Unit-Test nicht wirklich viel, seien Sie vorsichtig mit allem, was mit Thread-Sicherheit zu tun hat …
Da ist ein Gerätetest Prüfung auf Fadensicherheit:
/**
* Tests for ensuring Gson thread-safety.
*
* @author Inderjeet Singh
* @author Joel Leitch
*/
public class ConcurrencyTest extends TestCase {
private Gson gson;
...
Sie fragen sich vielleicht, ob dieser Komponententest ausreicht, um jedes mögliche Problem auf jeder möglichen Maschinenkonfiguration zu finden? Irgendwelche Kommentare dazu?
Die Gson-Instanz behält beim Aufrufen von Json-Vorgängen keinen Status bei. Es steht Ihnen also frei, dasselbe Objekt für mehrere Json-Serialisierungs- und Deserialisierungsvorgänge wiederzuverwenden.
Ich hätte gesagt, dass dieser Komponententest völlig unzureichend war, um Parallelitätsprobleme zu erkennen. Erstens ist MyObject eine triviale Klasse, an der keine komplexen Sammlungen beteiligt sind, sodass die gleichzeitige Deserialisierung von Listen und Karten und anderen komplexen Objekten nicht getestet wird. Zweitens wird die Serialisierung nur 10 Mal für jeden der 10 Threads wiederholt, was unzureichend ist. Drittens sind Nebenläufigkeitsfehler sowieso bekanntermaßen schwierig zu testen, da unterschiedliche Hardwarekonfigurationen unterschiedliche Laufzeiteigenschaften haben, sodass jeder Test nur dann gültig wäre, wenn garantiert ist, dass er auf allen Konfigurationen ausgeführt wird.
– Lawrence Dol
4. Dezember 2014 um 20:40 Uhr
Beispielsweise wird dieser Test wahrscheinlich keinen Parallelitätsfehler auf einem Computer mit einem Kern finden, da jeder Thread wahrscheinlich innerhalb eines einzigen Zeitabschnitts abgeschlossen wird und die Threads daher nacheinander und nicht gleichzeitig ausgeführt werden.
– Lawrence Dol
4. Dezember 2014 um 20:41 Uhr
Nein, um zu sagen, dass es nicht threadsicher ist, nur dass dieser Test nicht einmal im Entferntesten garantiert, dass dies der Fall ist.
– Lawrence Dol
4. Dezember 2014 um 20:43 Uhr
Die Frage „ob dieser Unit-Test ausreicht, um jedes mögliche Problem auf jeder möglichen Maschinenkonfiguration zu finden“ ist völlig irrelevant. Ich denke, jede Reihe von Tests wäre unmöglich, um alle möglichen Parallelitätsprobleme zu finden. Dass sie einen Test haben, ist ein guter Anfang, und dann sollte für jeden behobenen Parallelitätsfehler ein neuer Test erstellt werden. Außerdem ist dies Open Source, wenn Sie weitere Tests wünschen, gehen Sie und schreiben Sie sie.
– mjaggard
11. Juli um 10:45 Uhr
Vor einiger Zeit hatten wir Probleme mit der Thread-Sicherheit und wir haben es gelöst, indem wir das FastDateFormat in Apache Commons verwendet haben.
Habe gerade eine Zusammenfassung erstellt Link für Gist darum herum, um den Leuten zu helfen, die sich fragen, ob Gson-Instanzen wiederverwendet werden können. Sie haben keine Setter und alle Vars sind privat.
Abgesehen vom SimpleDateFormat-Problem sehe ich also nirgendwo anders, dass sie den Status beibehalten.
Überprüfen Sie es aus. Dies ist das erste Mal, dass ich auf eine davon antworte. Gerne einmal zurückgeben. 🙂
13441900cookie-checkIst es in Ordnung, die Gson-Instanz als statisches Feld in einer Model-Bean zu verwenden (Wiederverwendung)?yes
