分析无用单元收集器 (GC) 的日志文件以监视内存问题
建议您在生产环境中启用 GC 日志记录。有关如何启用 GC 日志记录的详细信息，请参阅
监视 ThingWorx 服务器的内存使用情况一节。启用 GC 日志记录后，将记录服务器上的所有 GC 活动。如果 JVM 长时间无响应，则外部工具 (如 PSM 或 VisualVM) 可能无法收集内存数据。但是，JVM 可以打印 GC 活动，这一功能可帮助您确定内存问题的原因。
读取 GC 日志
您可以使用 GCEasy.io 和 Chewiebug GC Viewer 等工具来分析 GC 日志。您还可以在文本编辑器中手动分析 GC 日志以查找常见问题。
通常会打印每个内存清理操作，如以下示例所示。
1. 自 JVM 启动以来的时间
2. GC 类型
3. GC 原因
4. 年轻代从 549M 清理到 4M
5. 年轻代总容量
6. GC 完成所需的总时间
7. 分配的堆
8. Java 正在清理的应用程序的内存总量
有关 GC 操作的详细信息，请参阅 Oracle 文档。
GC 分析工具会将清理的文本表示转换为可读性更强的图形。
分析 GC 日志中的数据可帮助您识别以下表示 ThingWorx 应用程序中存在内存问题的情景：
• 超长的完整 GC 操作 (45 秒以上) - 这些是极不可取的全局停止操作。例如，以下完整 GC 将花费 46 秒。在此期间，将停止所有其他用户活动：
272646.952: [Full GC: 7683158K->4864182K(8482304K) 46.204661 secs]
• 循环中发生的完整 GC - 这些是快速连续发生的完整 GC。
例如，以下四个连续的无用单元收集需要近两分钟才能解决：
16121.092: [Full GC: 7341688K->4367406K(8482304K), 38.774491 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
16160.11: [Full GC: 4399944K->4350426K(8482304K), 24.273553 secs]
16184.461: [Full GC: 4350427K->4350426K(8482304K), 23.465647 secs]
16207.996: [Full GC: 4350431K->4350427K(8482304K), 21.933158 secs]
• 在下图中，图形波峰上的红色三角形是循环中出现完整 GC 的直观指示：
• 内存泄漏 - 当内存中保留的对象数量增加且内存无法清理时，会发生这些问题。
在以下示例中，尽管存在无用单元收集器，内存仍会稳步增大：
建议 - 如果没有自动工具 (如 PSM) 可用于监视和记录内存随时间变化的使用情况，则请每日检查 GC 日志文件以确定是否存在内存问题。当出现内存问题时，请收集 JVM 线程转储或堆转储以确认长时间运行的操作。这些操作可触发 ThingWorx 应用程序中的潜在内存问题。