【发布时间】：2011-09-22 11:25:53
【问题描述】：
我遇到了两种不同的代码来解析带有StAX 的文件。快速谷歌搜索告诉我有两种解析方法：使用 cursor API 和使用 iterator API。请告诉我两者之间的区别以及从开发人员的角度来看哪一个更易于使用。
【问题讨论】：
【发布时间】：2011-09-22 11:25:53
【问题描述】：
如果你不解析长XML文件，那么你可以简单地使用JDOM，JDOM将整个XML加载到内存中并且速度较慢，但它非常好用。
【讨论】：
-
@oscarMk- JDOM 不存在问题，原因与您提到的相同 - 我使用的文件大小 > 200MB
您最有可能在 Java Web Services Developer Pack 教程或 Java EE 5 tutorial 的 StAX API 部分中找到答案。它们都包含我在下面复制的相同信息：
比较游标和迭代器 API
在光标和光标之间进行选择之前 迭代器 API，您应该注意一些 你可以用 您无法使用的迭代器 API 游标 API：
从 XMLEvent 子类创建的对象是不可变的，并且可以 用于数组、列表和映射，以及 可以通过你的 即使在解析器有 继续进行后续活动。
您可以创建 XMLEvent 的子类型，它们要么完全 新的信息项或扩展 现有项目，但有额外的 方法。
您可以更简单地在 XML 事件流中添加和删除事件 比使用游标 API 的方式。
同样，保留一些一般性 制作时要记住的建议 你的选择：
如果您正在为特别受内存限制的 环境，如J2ME，你可以使 更小，更高效的代码 游标 API。
如果性能是您的最高优先级 - 例如，在创建 低级库或 基础设施——游标API更多 高效。
如果要创建 XML 处理管道，请使用迭代器 API。
如果要修改事件流，请使用迭代器 API。
如果您希望您的应用程序能够处理可插拔处理 事件流，使用迭代器 API。
一般来说，如果您对一种方式或 其他，使用迭代器 API 是 推荐，因为它更多 灵活和可扩展，从而 “面向未来”您的应用程序。
虽然推荐使用迭代器 API，但它比游标 API 慢，因为游标不需要记住它之前解析过的节点；它提供对 XML 文档的只进解析，并且没有构造 XMLEvent 对象的开销。显然，a benchmark 表明，与 StAX 相比，SAX 在解析大型文档方面可能会更好。您可能想验证是否可以为您的数据集重现基准测试的结果。
【讨论】：
-
大文档问题的更新。您提供的链接来自 2011 年的结构化文档处理语言课程。我注意到您的评论来自 2011 年，但现在是 2014 年。我还没有进行新的基准测试，但仔细查看您链接上的课程信息，似乎大部分性能问题是由于 DOCTYPE 时的内存泄漏用过的。鉴于这个问题在 3 年前就已经被清楚地理解了，现在似乎已经解决了。还;即使在当时，StAX Cursor API 也具有最佳的整体性能 - 即使在较大的文件大小下也能很好地保持。
-
我知道这是一个旧答案，但仍然很好奇：迭代器 API 记住以前节点的任何代码示例？我找不到任何证据。