我描述了一个 jdbc/hibernate 批量导入器。它需要一个 csv 对其进行轻微转换，并将其导入到位于本地主机的数据库中。
令我惊讶的是，该操作不是 I/O 绑定(bind)而是 cpu 绑定(bind)。
根据 jmx/jconsole 以及 netbeans 分析器，看起来 60% 的 cpu 时间花在了“老一代”垃圾收集器上 其余用于几何转换(这是合理的)和 hibernate session 管理。
根据 jconsole，其他应用程序使用了大约 5-10% 那么对于此类批量插入任务，cpu/young GC/old GC 的“典型”比率是多少？
最佳答案
60% 确实很高。这通常表明有人使用了很多临时字符串或类似的东西。它发生在“老一代”的事实表明它可能发生在数据库端，也许是在等待数据库事务发生时。但这只是马背上的猜测。
您可能想要对运行进行更详细的分析。
关于java - 健康的垃圾收集指标？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/902660/