文档生成使用开源项目FOP的0.20.5工具（目前他们在重新设计一个新的版本）来生成PDF文档。OutOfMemoryError是一个已知的严重问题，我深入到FOP的源码中，发现主要导致OutOfMemoryError的地方有两个：
    （首先我理解JVM的OutOfMemoryError不知道对不对，因为JVM会有内存回收机制，而我也不知道具体内在的实现，所以我只是猜测其实现，如果有错误，请指正。我认为JVM的内存管理也是对碎片的管理与回收，一开始内存不断地被申请，回收机制不启动，直到内存临近限制的阈值，回收机制启动，回收部分内存，导致内存中存在碎片，当然如果JVM的时间中能够内存碎片整理，重新得到一大片内存，不过碎片整理需要更多的回收处理时间，可能JVM不会轻易处理，同时如果有些内存不能进行移动拷贝合并的话，碎片整理就可能受到限制，譬如一些Map或者Set类型的变量可能对内存的移动会敏感。我这里假设 JVM不能完成碎片整理，而导致随着内存的不断申请，而又不能够完全地被释放，最终形成碎片窟窿。最后申请大片的内存不能满足而 OutOfMemoryError。上述都只是我的猜测，没有理论根据，请指正。）
    1．PDF文档最后会根据已有的文字，从对应的字体库中读取对应的字体信息附在文件后面，由于要搜索对应字符的字体信息，所以FOP实现中采用了将整个字体文件读入内存中作为一个数组进行查询，这对于西方文字来说，整个字体文件大约300k，不会出现很大问题；但是对于亚洲语种来说，一个字体文件可能就是 10几M，譬如我们常用的宋体，在windows中就是10M，无疑将文档生成后期，内存已经是被JVM申请释放搞得碎片多多，从而要求一整片10M的空间会使得JVM无法处理，
而最后只有OutOfMemoryError。
    2．PDF对于页面上的元素，譬如图片的处理则是先从图片文件中提取所有的点阵信息，放在一片数组内存中，然后在写入PDF文件的时候则采用类似PNG图片的压缩方法（是否就是PNG所使用的LZ77压缩算法还要研究查实）将这些点阵数组内存中的数据压缩写入文件的方法。这个过程中会由于实现的原因会使得存在两个点阵数组，譬如针对1024x1024的图片，则要求同时存在一个4x1024x1024和一个3x1024x1024的内存片，其中4是 sizeof(int)，而3是sizeof(r,g,b)，如此就对内存的申请导致了和字体文件同样的问题，就是最后因为JVM内部的碎片问题导致内存不足而报OutOfMemoryError。

    针对第一个问题，已经解决，就是不直接读取字体文件到内存，而是直接的RandomAccessFile的调用，从而已经一定程度上解决了不是很大的PDF文档生成也会报OutOfMemoryError的问题。
    针对第二个问题，解决难度相对较大，因为图片的格式有gif、png、jpeg等，而且中间的转换过程有解压和重新压缩的问题，如果保存的压缩格式不对，会导致图片显示不正确。而且我看了FOP中源代码受这个解压和重新压缩设计思路影响的代码
比较多。不过如果就生成速度和效率以及性能方面来说是值得深入修改的。对于PNG文件的一个体会，前面生成大项目文档生成的优化过程中，有一个重要的步骤就是改用*.gif成为*.png而导致RTF文档生成的大幅度提高，其实就是PNG编码的改变，由于RTF中保存文件采用PNG格式，从而对于*.gif需要进行解压和重新PNG压缩从而需要的时间比较长，而对于 *.png不用解压重新压缩，从而速度大幅提升。现在PDF的生成过程中则不针对*.png进行优化，则同样对*.png进行PNG解压，再对数据进行 PNG压缩，做了无用功，导致速度大为降低，而且还有内存的性能问题。

    我对现在的PDF文档生成作了一些测试，大约如果单一构件内包含80个逻辑（含有图片的逻辑），这个构件对应地占有PDF中一个大约200页的容器，则需要约210多M内存来生成，粗略推算（关于OutOfMemoryError的推算很难），则对于如果包含超过300个含图片的逻辑的构件至少需要 450M的内存。不过对于真的大项目的PDF文档生成，要求加内存参数至450M也是可以接受的。
    就优化的余地来说，我参照FOP上给出的几条优化建议
http://xml.apache.org/fop/running.html#memory
我觉得还可以做的就是改动FOP内部的图片处理代码了，虽然上面没有提及。

    就我个人意见，应该对PDF的FOP代码进行优化，不过可能需要相对较多的时间来研究优化（至少要一周，我觉得），当然我们也可以等待FOP的新版本，不过开源的发布速度发布时间不是很确定。