@yidinghe 感谢回复。
1、确认后没有内存泄漏，一次 FullGC 之后内存基本和刚启动时一样.但是一次 10 并发，基本就要 Full GC 一次，楼下也有大佬提出修改 young 和 old,我试一下看看，将 young 设置大一点。
2、对于取一条数据解析一条，嗯。。其实一直有个疑惑,while(resultSet.next （））的时候,这个 resultSet.next 是不是就相当于一个游标，其实数据还是存在于数据库端的？还是说不同数据库有不同的实现方式？

@sadfQED2 感谢回复。数据要求实时查询。加机器配置这个事情，难呀。

@bobuick 目前我单纯的本地写个 for 循环去触发查询接口，基本上每调用 9 次就会触发一次 Full GC,之后内存迅速下降,基本等于刚启动时候的内存。 改改参数看吧，也是第一次遇到这种问题

@BBCCBB 感谢回复。G1 会尝试一下的。

@l8g 感谢回复。楼上也有大佬提到修改 young 和 old，我会试一下的。 说起来，拆分查询也是一个头疼的事情，目前底层存储库不支持这种比如 limit 这种拆分查询

@babyvox5th 数据 JDBC 查询完，就是内存操作了目前。

@bobuick 感谢回复。young 设置大一点我会验证试一下的。这是第一次遇到这种 GC 问题，不知像互联网那些高并发项目，Full GC 频率的合理范围是多少呢？还请指教

@ipwx 嗯，以前 hbase 做存储时已经是结构化的数据了，但是后来换了数据库必须要调用方去解析这些数据。其实整体数据流程很简单，jdbc 查询，查完解析入库。

@jimrok 补充：是单次请求解析需 2-4s

@jimrok 数据流程大概是这样，第一步 jdbc 查库，第二步:对每条数据做解析，第三步:入 redis。 目前问题主要集中在解析这个过程 32 核机器跑满也需要 2-4s，稍微来个并发(不到 10 个)，10g 的堆因为 gc 导致解析时间会上升到 20s+

@chendy 需求大概是这样的:从数据库查出 30000 条数据，数据部分字段会包含长文本，单条数据约 200+字段，查出后需要对数据解析，据观察内存涨幅约等于 900m