Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#1,091 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
45/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
java
Lĩnh vực
backend, performance

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Java
Star
4.7k
Fork
2.6k
Merge trung bình
4 ngày 11 giờ
Pull request đã merge (30 ngày)
7

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của stleary/JSON-java

Tất cả issue của stleary/JSON-java

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.