Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Parsing large object tree keeps a separate copy of every key in every object

Offen
  • Stimmt etwas nicht?
#1,091 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
45/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
java
Bereich
backend, performance

Rechercherichtung

Start with JSONTokener.nextString, nextSimpleValue, and nextValue, then trace how JSONObject parses and stores keys; the issue explains the repeated-string memory cost and the existing subclass workaround. Compare the opt-in configuration, default behavior, and key-map size cap options, then add unit tests for key sharing and ensure values are not shared. Done means the chosen API behaves as documented and default parsing remains unchanged.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Investigating

What we were doing

We run a web application that takes bulk inserts as JSON. A request body has an array of row objects that all use the same keys, for example {"rows": [{"name": "a", "count": 1, ...}, {"name": "b", "count": 2, ...}, ...]}. We parse it with new JSONObject(new JSONTokener(reader)). A request can have thousands of rows with dozens of keys each.

Result

JSONTokener.nextString creates a new String for every key it reads. A key that appears in 10,000 rows is stored 10,000 times. A heap dump from one of our production servers with 41 bulk-insert requests in progress showed 1.88 GB of parsed JSON, about 108 bytes per cell. Approximately half of that was repeated copies of the same String keys.

Expected result

Each distinct key should be stored once per parse. Since your README includes "low memory footprint" as a project goal, we're hoping you'd entertain a change.

Current workaround

We subclass JSONTokener and override nextString to return one shared instance per distinct key: KeySharingJSONTokener.java. This depends on internal details: keys are read through nextSimpleValue → nextString, but quoted values go through the same nextString. To keep values out of the shared map, we also override nextValue and handle quoted values there. A future change to these internals could quietly stop keys from being shared, or start sharing values.

Proposal

Add an opt-in option, JSONParserConfiguration.withShareKeys(boolean), that is off by default. When it's on, JSONObject swaps each parsed key for an earlier identical key from the same parse. The map of seen keys is held only for the length of one parse, and it is capped so input with a huge number of unique keys can't make it grow without limit. With the default configuration, no input would parse differently.

Alternatively, if you like this approach (I don't see much downside) it could be enabled by default.

If you'd rather not add a configuration option, a documented protected method on JSONTokener that is called only for keys would also make our subclass more reliable.

We're happy to send a PR, with unit tests and Java 6-compatible code, for whichever approach you prefer. Our code linked above is Apache 2.0 but we are happy to submit a contribution here as public domain.

Vorherrschende Sprache
Java
Sterne
4.7k
Forks
2.6k
Ø Merge
4 T. 11 Std.
Gemergte PRs (30 T.)
7

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus stleary/JSON-java

Alle Issues in stleary/JSON-java

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.