Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

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

Ouverte
  • Quelque chose ne va pas ?
#1,091 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
45/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
java
Domaine
backend, performance

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Java
Étoiles
4.7k
Forks
2.6k
Merge moyen
4 j 11 h
PR mergées (30 j)
7

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de stleary/JSON-java

Toutes les issues de stleary/JSON-java

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.