测试过大输入的代码

在编写单元测试时，我们主要关注业务的正确性。我们将竭尽所能，开开心心地走在最前沿。我们有时会进行微基准测试并衡量吞吐量。但是经常遗漏的一个方面是当输入过大时我们的代码如何表现？我们测试了如何处理正常的输入文件，格式错误的文件，空文件，丢失的文件……但是对于超大的输入文件呢？

让我们从一个真实的用例开始。您已获得将GPX （ GPS交换格式 ，基本上为XML）实现为JSON转换的任务。我选择GPX的原因并不特别，它只是您可能遇到的另一种XML格式，例如在用GPS接收器记录远足或骑自行车时。我还认为使用XML中的一些标准而不是另一个“人员数据库”会很好。 GPX文件中有数百个平面<wpt/>条目，每个条目代表时空的一点：

<gpx><wpt lat="42.438878" lon="-71.119277"><ele>44.586548</ele><time>2001-11-28T21:05:28Z</time><name>5066</name><desc><![CDATA[5066]]></desc><sym>Crossing</sym><type><![CDATA[Crossing]]></type></wpt><wpt lat="42.439227" lon="-71.119689"><ele>57.607200</ele><time>2001-06-02T03:26:55Z</time><name>5067</name><desc><![CDATA[5067]]></desc><sym>Dot</sym><type><![CDATA[Intersection]]></type></wpt><!-- ...more... -->
</gpx>

完整示例： www.topografix.com/fells_loop.gpx 。我们的任务是提取每个单独的<wpt/>元素，丢弃没有lat或lon属性的元素，并以以下格式存储回JSON：

[{"lat": 42.438878,"lon": -71.119277},{"lat": 42.439227,"lon": -71.119689}...more...
]

这很容易！首先，我从使用JDK和GPX 1.0 XSD架构的 xjc实用程序生成JAXB类开始。请注意，GPX 1.1是撰写本文时的最新版本，但是我得到的示例使用1.0。对于JSON编组，我使用了Jackson 。完整，可运行且经过测试的程序如下所示：

import org.apache.commons.io.FileUtils;
import org.codehaus.jackson.map.ObjectMapper;
import javax.xml.bind.JAXBException;public class GpxTransformation {private final ObjectMapper jsonMapper = new ObjectMapper();private final JAXBContext jaxbContext;public GpxTransformation() throws JAXBException {jaxbContext = JAXBContext.newInstance("com.topografix.gpx._1._0");}public void transform(File inputFile, File outputFile) throws JAXBException, IOException {final List<Gpx.Wpt> waypoints = loadWaypoints(inputFile);final List<LatLong> coordinates = toCoordinates(waypoints);dumpJson(coordinates, outputFile);}private List<Gpx.Wpt> loadWaypoints(File inputFile) throws JAXBException, IOException {String xmlContents = FileUtils.readFileToString(inputFile, UTF_8);final Unmarshaller unmarshaller = jaxbContext.createUnmarshaller();final Gpx gpx = (Gpx) unmarshaller.unmarshal(new StringReader(xmlContents));return gpx.getWpt();}private static List<LatLong> toCoordinates(List<Gpx.Wpt> waypoints) {return waypoints.stream().filter(wpt -> wpt.getLat() != null).filter(wpt -> wpt.getLon() != null).map(LatLong::new).collect(toList());}private void dumpJson(List<LatLong> coordinates, File outputFile) throws IOException {final String resultJson = jsonMapper.writeValueAsString(coordinates);FileUtils.writeStringToFile(outputFile, resultJson);}}class LatLong {private final double lat;private final double lon;LatLong(Gpx.Wpt waypoint) {this.lat = waypoint.getLat().doubleValue();this.lon = waypoint.getLon().doubleValue();}public double getLat() { return lat; }public double getLon() { return lon; }
}

看起来还不错，尽管我故意留下了一些陷阱。我们加载GPX XML文件，将航点提取到List ，然后将该列表转换为轻量级的LatLong对象，首先过滤掉损坏的航点。最后，我们将List<LatLong>转储到磁盘。然而，有一天，极其漫长的自行车骑行使我们的系统因OutOfMemoryError崩溃。你可知道发生了什么？上传到我们的应用程序的GPX文件很大，比我们预期的要大得多。现在再看一下上面的实现，并计算在多少地方分配了必要的内存？

但是，如果您想立即进行重构，请就在此处停止！我们想练习TDD，对吗？我们要在代码中限制WTF /分钟因素吗？我有一个理论，许多“ WTF”不是由粗心和缺乏经验的程序员引起的。通常是由于周五晚些时候的生产问题，完全出乎意料的输入和不可预料的副作用。代码获得了越来越多的变通办法，难以理解的重构，以及比人们预期的更复杂的逻辑。有时不希望有错误的代码，但是由于我们早已忘记了这种情况，所以需要这样做。因此，如果有一天您看到不可能发生的null检查或可能已被库替换的手写代码，请考虑上下文。话虽这么说，让我们从编写测试开始以证明我们将来的重构是必要的。如果有一天有人“固定”我们的代码，并假设“这位愚蠢的程序员”在没有充分理由的情况下使事情复杂化，那么自动化测试将准确地说明原因。

我们的测试将仅尝试转换疯狂的大输入文件。但是在开始之前，我们必须对原始实现进行一些重构，以使其能够容纳InputStream和OutputStream而不是输入和输出File －没有理由将我们的实现仅限于文件系统：

步骤0a：使其可测试

import org.apache.commons.io.IOUtils;public class GpxTransformation {//...public void transform(File inputFile, File outputFile) throws JAXBException, IOException {try (InputStream input =new BufferedInputStream(new FileInputStream(inputFile));OutputStream output =new BufferedOutputStream(new FileOutputStream(outputFile))) {transform(input, output);}}public void transform(InputStream input, OutputStream output) throws JAXBException, IOException {final List<Gpx.Wpt> waypoints = loadWaypoints(input);final List<LatLong> coordinates = toCoordinates(waypoints);dumpJson(coordinates, output);}private List<Gpx.Wpt> loadWaypoints(InputStream input) throws JAXBException, IOException {String xmlContents = IOUtils.toString(input, UTF_8);final Unmarshaller unmarshaller = jaxbContext.createUnmarshaller();final Gpx gpx = (Gpx) unmarshaller.unmarshal(new StringReader(xmlContents));return gpx.getWpt();}//...private void dumpJson(List<LatLong> coordinates, OutputStream output) throws IOException {final String resultJson = jsonMapper.writeValueAsString(coordinates);output.write(resultJson.getBytes(UTF_8));}}

步骤0b：编写输入（压力）测试

使用先前开发的 repeat(byte[] sample, int times)实用工具将从头开始生成输入。我们基本上将重复相同的<wpt/>项数百万次，并用GPX页眉和页脚将其包装起来，以便其格式正确。通常，我会考虑将样本放在src/test/resources ，但是我希望此代码能够自我包含。注意，我们既不在乎实际的输入，也不在乎输出。这已经过测试。如果转换成功（如果需要，我们可以添加一些超时），那就可以了。如果它因任何异常而失败，很可能是OutOfMemoryError ，则是测试失败（错误）：

import org.apache.commons.io.FileUtils
import org.apache.commons.io.output.NullOutputStream
import spock.lang.Specification
import spock.lang.Unrollimport static org.apache.commons.io.FileUtils.ONE_GB
import static org.apache.commons.io.FileUtils.ONE_KB
import static org.apache.commons.io.FileUtils.ONE_MB@Unroll
class LargeInputSpec extends Specification {final GpxTransformation transformation = new GpxTransformation()final byte[] header = """<?xml version="1.0"?><gpxversion="1.0"creator="ExpertGPS 1.1 - http://www.topografix.com"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns="http://www.topografix.com/GPX/1/0"xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd"><time>2002-02-27T17:18:33Z</time>""".getBytes(UTF_8)final byte[] gpxSample = """<wpt lat="42.438878" lon="-71.119277"><ele>44.586548</ele><time>2001-11-28T21:05:28Z</time><name>5066</name><desc><![CDATA[5066]]></desc><sym>Crossing</sym><type><![CDATA[Crossing]]></type></wpt>""".getBytes(UTF_8)final byte[] footer = """</gpx>""".getBytes(UTF_8)def "Should not fail with OOM for input of size #readableBytes"() {given:int repeats = size / gpxSample.lengthInputStream xml = withHeaderAndFooter(RepeatedInputStream.repeat(gpxSample, repeats))expect:transformation.transform(xml, new NullOutputStream())where:size << [ONE_KB, ONE_MB, 10 * ONE_MB, 100 * ONE_MB, ONE_GB, 8 * ONE_GB, 32 * ONE_GB]readableBytes = FileUtils.byteCountToDisplaySize(size)}private InputStream withHeaderAndFooter(InputStream samples) {InputStream withHeader = new SequenceInputStream(new ByteArrayInputStream(header), samples)return new SequenceInputStream(withHeader, new ByteArrayInputStream(footer))}
}

实际上，这里有7个测试，运行GPX到JSON转换以输入大小：1 KiB，1 MiB，10 MiB，100 MiB，1 GiB，8 GiB和32 GiB。我在JDK 8u11x64上使用以下选项运行这些测试： -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xmx1g 。 1 GiB的内存很多，但是显然不能容纳整个输入文件在内存中：

当小测试通过时，高于1 GiB的输入将快速失败。

步骤1：避免将整个文件保留在

堆栈跟踪揭示了问题所在：

java.lang.OutOfMemoryError: Java heap spaceat java.util.Arrays.copyOf(Arrays.java:3326)at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:137)at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:121)at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:569)at java.lang.StringBuilder.append(StringBuilder.java:190)at org.apache.commons.io.output.StringBuilderWriter.write(StringBuilderWriter.java:138)at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:2002)at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1980)at org.apache.commons.io.IOUtils.copy(IOUtils.java:1957)at org.apache.commons.io.IOUtils.copy(IOUtils.java:1907)at org.apache.commons.io.IOUtils.toString(IOUtils.java:778)at com.nurkiewicz.gpx.GpxTransformation.loadWaypoints(GpxTransformation.java:56)at com.nurkiewicz.gpx.GpxTransformation.transform(GpxTransformation.java:50)

loadWaypoints急切地将input GPX文件加载到String （请参阅： IOUtils.toString(input, UTF_8) ），以便稍后对其进行解析。这有点愚蠢，尤其是因为JAXB Unmarshaller可以轻松地直接读取InputStream 。让我们修复它：

private List<Gpx.Wpt> loadWaypoints(InputStream input) throws JAXBException, IOException {final Unmarshaller unmarshaller = jaxbContext.createUnmarshaller();final Gpx gpx = (Gpx) unmarshaller.unmarshal(input);return gpx.getWpt();
}private void dumpJson(List<LatLong> coordinates, OutputStream output) throws IOException {jsonMapper.writeValue(output, coordinates);
}

同样，我们修复了dumpJson因为它首先将JSON转储到String ，然后将该String复制到OutputStream 。结果略好一些，但再次出现1 GiB失败，这一次是进入Full GC的无限死亡循环，最后抛出：

java.lang.OutOfMemoryError: Java heap spaceat com.sun.xml.internal.bind.v2.runtime.unmarshaller.LeafPropertyLoader.text(LeafPropertyLoader.java:50)at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallingContext.text(UnmarshallingContext.java:527)at com.sun.xml.internal.bind.v2.runtime.unmarshaller.SAXConnector.processText(SAXConnector.java:208)at com.sun.xml.internal.bind.v2.runtime.unmarshaller.SAXConnector.endElement(SAXConnector.java:171)at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:609)[...snap...]at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:649)at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal0(UnmarshallerImpl.java:243)at com.sun.xml.internal.bind.v2.runtime.unmarshaller.UnmarshallerImpl.unmarshal(UnmarshallerImpl.java:214)at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:157)at javax.xml.bind.helpers.AbstractUnmarshallerImpl.unmarshal(AbstractUnmarshallerImpl.java:204)at com.nurkiewicz.gpx.GpxTransformation.loadWaypoints(GpxTransformation.java:54)at com.nurkiewicz.gpx.GpxTransformation.transform(GpxTransformation.java:47)

步骤2 ：（以较差的方式）用StAX替换JAXB

我们可以怀疑，现在的主要问题是使用JAXB进行XML解析，JAXB总是将整个XML文件映射到Java对象中。很难想象为什么将1 GiB文件转换为对象图会失败。我们想以某种方式更好地控制读取XML并将其分块使用。传统上在这种情况下使用SAX，但是SAX API中的推式编程模型非常不便。 SAX使用回调机制，该机制具有很高的侵入性，并且不易读。 StAX（用于XML的流API）在更高级别上工作，公开了拉模型。这意味着客户代码决定何时以及消耗多少输入。这使我们可以更好地控制输入，并具有更大的灵活性。为了使您熟悉该API，以下代码几乎等同于loadWaypoints() ，但是我跳过了<wpt/>属性，这些属性以后不再需要：

private List<Gpx.Wpt> loadWaypoints(InputStream input) throws JAXBException, IOException, XMLStreamException {final XMLInputFactory factory = XMLInputFactory.newInstance();final XMLStreamReader reader = factory.createXMLStreamReader(input);final List<Gpx.Wpt> waypoints = new ArrayList<>();while (reader.hasNext()) {switch (reader.next()) {case XMLStreamConstants.START_ELEMENT:if (reader.getLocalName().equals("wpt")) {waypoints.add(parseWaypoint(reader));}break;}}return waypoints;
}private Gpx.Wpt parseWaypoint(XMLStreamReader reader) {final Gpx.Wpt wpt = new Gpx.Wpt();final String lat = reader.getAttributeValue("", "lat");if (lat != null) {wpt.setLat(new BigDecimal(lat));}final String lon = reader.getAttributeValue("", "lon");if (lon != null) {wpt.setLon(new BigDecimal(lon));}return wpt;
}

看看我们如何明确地向XMLStreamReader请求更多数据？然而事实是，我们正在使用更多的低级别的API（和更大量的代码），并不意味着它必须是更好的，如果使用不当。我们一直在构建庞大的waypoints列表，因此再次看到OutOfMemoryError也就不足为奇了：

java.lang.OutOfMemoryError: Java heap spaceat java.util.Arrays.copyOf(Arrays.java:3204)at java.util.Arrays.copyOf(Arrays.java:3175)at java.util.ArrayList.grow(ArrayList.java:246)at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:220)at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:212)at java.util.ArrayList.add(ArrayList.java:443)at com.nurkiewicz.gpx.GpxTransformation.loadWaypoints(GpxTransformation.java:65)at com.nurkiewicz.gpx.GpxTransformation.transform(GpxTransformation.java:52)

正是我们所期望的。好消息是，1个吉布测试通过（1个吉布堆），所以我们有几分在正确的方向前进。但是由于GC过多，需要1分钟才能完成。

步骤3：正确实施StAX

注意，在前面的示例中使用StAX的实现与SAX一样好。但是，我选择StAX的原因是我们现在可以将XML文件转换为Iterator<Gpx.Wpt> 。该迭代器仅在被询问时才懒散地使用XML文件。以后我们也可以延迟使用该迭代器，这意味着我们不再将整个文件保留在内存中。迭代器虽然笨拙，但比直接使用XML或使用SAX回调要好得多：

import com.google.common.collect.AbstractIterator;private Iterator<Gpx.Wpt> loadWaypoints(InputStream input) throws JAXBException, IOException, XMLStreamException {final XMLInputFactory factory = XMLInputFactory.newInstance();final XMLStreamReader reader = factory.createXMLStreamReader(input);return new AbstractIterator<Gpx.Wpt>() {@Overrideprotected Gpx.Wpt computeNext() {try {return tryPullNextWaypoint();} catch (XMLStreamException e) {throw Throwables.propagate(e);}}private Gpx.Wpt tryPullNextWaypoint() throws XMLStreamException {while (reader.hasNext()) {int event = reader.next();switch (event) {case XMLStreamConstants.START_ELEMENT:if (reader.getLocalName().equals("wpt")) {return parseWaypoint(reader);}break;case XMLStreamConstants.END_ELEMENT:if (reader.getLocalName().equals("gpx")) {return endOfData();}break;}}throw new IllegalStateException("XML file didn't finish with </gpx> element, malformed?");}};
}

这变得越来越复杂！我正在使用来自Guava的AbstractIterator来处理乏味的hasNext()状态。每次有人尝试从迭代器中提取下一个Gpx.Wpt项（或调用hasNext() ）时，我们都会消耗一点XML，足以返回一个条目。如果XMLStreamReader遇到XML的结尾（ </gpx>标记），我们将通过返回endOfData()通知迭代器结束。这是一种非常方便的模式，其中XML被懒惰地读取并通过方便的迭代器提供服务。仅此实现就消耗很少的，恒定的内存量。但是，我们将API从List<Gpx.Wpt>更改为Iterator<Gpx.Wpt> ，这将强制更改其余实现：

private static List<LatLong> toCoordinates(Iterator<Gpx.Wpt> waypoints) {final Spliterator<Gpx.Wpt> spliterator =Spliterators.spliteratorUnknownSize(waypoints, Spliterator.ORDERED);return StreamSupport.stream(spliterator, false).filter(wpt -> wpt.getLat() != null).filter(wpt -> wpt.getLon() != null).map(LatLong::new).collect(toList());
}

toCoordinates()以前接受List<Gpx.Wpt> 。迭代器无法直接转换为Stream ，因此我们需要通过Spliterator笨拙的转换。你认为结束了吗？！ GiB测试通过得更快一些，但更多苛刻的测试却像以前一样失败了：

java.lang.OutOfMemoryError: Java heap spaceat java.util.Arrays.copyOf(Arrays.java:3175)at java.util.ArrayList.grow(ArrayList.java:246)at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:220)at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:212)at java.util.ArrayList.add(ArrayList.java:443)at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169)at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)at java.util.Iterator.forEachRemaining(Iterator.java:116)at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:512)at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502)at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)at com.nurkiewicz.gpx.GpxTransformation.toCoordinates(GpxTransformation.java:118)at com.nurkiewicz.gpx.GpxTransformation.transform(GpxTransformation.java:58)at com.nurkiewicz.LargeInputSpec.Should not fail with OOM for input of size #readableBytes(LargeInputSpec.groovy:49)

请记住，并非总是从实际上消耗大量内存的地方抛出OutOfMemoryError 。幸运的是，这次并非如此。仔细查看底部： collect(toList()) 。

步骤4：避免流和收集器

这真令人失望。溪流和收集器的设计完全是为了支持懒惰。但是，实际上不可能有效地实现从流到迭代器的收集器（另请参见： Java 8中编写自定义收集器以及分组，采样和批处理–自定义收集器的简介 ），这是一个很大的设计缺陷。因此，我们必须完全忘记流，并一直使用简单的迭代器。迭代器不是很优雅，但是可以逐项消耗输入，可以完全控制内存消耗。我们需要一种方法来filter()输入迭代器，丢弃损坏的项并将map()条目map()到另一个表示形式。番石榴再次提供了一些方便的实用程序，完全替换了stream() ：

private static Iterator<LatLong> toCoordinates(Iterator<Gpx.Wpt> waypoints) {final Iterator<Gpx.Wpt> filtered = Iterators.filter(waypoints, wpt -> wpt.getLat() != null && wpt.getLon() != null);return Iterators.transform(filtered, LatLong::new);
}

Iterator<Gpx.Wpt>在， Iterator<LatLong>出。没有进行任何处理，几乎没有触及XML文件，几乎没有内存消耗。我们很幸运，杰克逊接受迭代器并透明地读取它们，从而迭代生成JSON。因此，存储器消耗也保持较低。猜猜是什么，我们做到了！

内存消耗低且稳定，我认为我们可以放心地假设它是恒定的。我们的代码以大约40 MiB / s的速度处理，因此处理32 GiB大约需要14分钟，不要感到惊讶。哦，我是否提到我使用-Xmx32M运行了最后一个测试？没错，使用少千倍的内存即可成功处理32 GiB，而不会造成任何性能损失。与初始实施相比，减少了3000倍。事实上，最后一个使用迭代器的解决方案甚至能够处理无限的XML流。这实际上不只是理论上的情况，想象一下某种流API会产生永无止境的消息流…

最终实施

这是我们完整的代码：

package com.nurkiewicz.gpx;import com.google.common.base.Throwables;
import com.google.common.collect.AbstractIterator;
import com.google.common.collect.Iterators;
import com.topografix.gpx._1._0.Gpx;
import org.codehaus.jackson.map.ObjectMapper;import javax.xml.bind.JAXBException;
import javax.xml.stream.XMLInputFactory;
import javax.xml.stream.XMLStreamConstants;
import javax.xml.stream.XMLStreamException;
import javax.xml.stream.XMLStreamReader;
import java.io.BufferedInputStream;
import java.io.BufferedOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.math.BigDecimal;
import java.util.Iterator;public class GpxTransformation {private static final ObjectMapper jsonMapper = new ObjectMapper();public void transform(File inputFile, File outputFile) throws JAXBException, IOException, XMLStreamException {try (InputStream input =new BufferedInputStream(new FileInputStream(inputFile));OutputStream output =new BufferedOutputStream(new FileOutputStream(outputFile))) {transform(input, output);}}public void transform(InputStream input, OutputStream output) throws JAXBException, IOException, XMLStreamException {final Iterator<Gpx.Wpt> waypoints = loadWaypoints(input);final Iterator<LatLong> coordinates = toCoordinates(waypoints);dumpJson(coordinates, output);}private Iterator<Gpx.Wpt> loadWaypoints(InputStream input) throws JAXBException, IOException, XMLStreamException {final XMLInputFactory factory = XMLInputFactory.newInstance();final XMLStreamReader reader = factory.createXMLStreamReader(input);return new AbstractIterator<Gpx.Wpt>() {@Overrideprotected Gpx.Wpt computeNext() {try {return tryPullNextWaypoint();} catch (XMLStreamException e) {throw Throwables.propagate(e);}}private Gpx.Wpt tryPullNextWaypoint() throws XMLStreamException {while (reader.hasNext()) {int event = reader.next();switch (event) {case XMLStreamConstants.START_ELEMENT:if (reader.getLocalName().equals("wpt")) {return parseWaypoint(reader);}break;case XMLStreamConstants.END_ELEMENT:if (reader.getLocalName().equals("gpx")) {return endOfData();}break;}}throw new IllegalStateException("XML file didn't finish with </gpx> element, malformed?");}};}private Gpx.Wpt parseWaypoint(XMLStreamReader reader) {final Gpx.Wpt wpt = new Gpx.Wpt();final String lat = reader.getAttributeValue("", "lat");if (lat != null) {wpt.setLat(new BigDecimal(lat));}final String lon = reader.getAttributeValue("", "lon");if (lon != null) {wpt.setLon(new BigDecimal(lon));}return wpt;}private static Iterator<LatLong> toCoordinates(Iterator<Gpx.Wpt> waypoints) {final Iterator<Gpx.Wpt> filtered = Iterators.filter(waypoints, wpt ->wpt.getLat() != null &&wpt.getLon() != null);return Iterators.transform(filtered, LatLong::new);}private void dumpJson(Iterator<LatLong> coordinates, OutputStream output) throws IOException {jsonMapper.writeValue(output, coordinates);}}

摘要（TL; DR）

如果您没有足够的耐心执行所有步骤，则可以参考以下三点：

您的首要目标是简单 。最初的JAXB实现非常好（只需进行少量修改），如果您的代码不必处理大量输入，则应保持这种状态。
针对巨大的输入 （例如，使用生成的InputStream ）生成千兆字节的输入，以测试您的代码 。巨大的数据集是边缘情况的另一个例子。一次不要手动测试。一不小心的更改或“改进”可能会破坏您的性能。
优化不是编写不良代码的借口 。请注意，我们的实现仍然是可组合的，并且易于遵循。如果我们通过SAX并简单地内联SAX回调中的所有逻辑，则可维护性将受到很大影响。