※ 引述《lovdkkkk (dk)》之铭言： : 有理， : 不过 by this case... : 先说一下关於 Apache POI， : 如果没有自己 handle Streaming Usermodel，那它本身就非常吃记忆体， : 详情请自行估狗 "Apache POI Footprint" or "Apache POI OutOfMemory"， : 最近是有改善但有限。 : 所以真的怕大档吃 memory 的话，其实就... : pipe 或什麽其它的 stream 让你 GG 之前， : Apache POI 会先让你 GG XDD。 把 Apache POI 和原本的读档程式用 pipe 接起来，最高吃 1.1 GB 记忆体 纯跑原版读档程式则 800 MB，好像还好(?) 附带一提，我有 8G RAM，用 64 位元 Java 跑，所以目前记忆体使用量暂时不是问题 : 写一个 byte 读一个 byte 其实也有点...奇怪？ : 因为用 Apache POI 我没会错意的话， : 应该是要靠它拿 cell 里的值然後自己加逗号， : 特地对後来建出的字串一个一个 byte 处理... : 不知道该怎麽说 "0rz : 前面 Apache POI 应该已经吃掉 : 比你把资料全读出来组好的 String 还多 n 倍的 memory 了， : 这里真的要抢回 memory 的话尽快把资料读完， : 让 HSSF/XSSF workbook 设为 null 给 GC 最有效， : 不然都有种 "省小条、开大条" 的感觉 @@"。 不小心让各位会错意了，真抱歉 我是出於好奇，认为 pipe 会 block 很奇怪， 为了想问出会 block 的原因，才举个读写 1 byte 的例子 XD 实际上的程式是 PrintWriter→OutputStreamWriter→PipedOutputStream 再来读取是 PipedInputStream→BufferedInputStream→Scanner (BufferedInputStream 是原本为了读 File 准备的，转成 PipedInputStream 後没拿掉) : 至於简单，用 pipe input/output 互接看起来是有一点麻烦， : 不过写档也一样要读出资料、加逗号再存成 CSV， : 那或许可以考虑用简单一点的 PrintStream， : (是说它也可以写档就是) : 只要一直读出来 append... append...， : 读完再拿 byte array 转 input stream 就好， : 这样也是都在 memory 里做掉，不过还是很简单。 如上段回应，PrintWriter→OutputStreamWriter→PipedOutputStream 不需要自己解决 byte array 用 PrintWriter 不用 PrintStream 的理由是需要固定用 UTF-16LE 编码 : ※ 引述《popcorny (毕业了..@@")》之铭言： : : 读写档比memory慢，这个是绝对的 : : 但是回到原po说的 : : 他想要写一个byte读一个byte 一样很抱歉让你误解了 XD : : 然而producer是apache poi 而consumer是已经写好的程式 : : 所以要这样"Flow Control"应该很难写吧... : : 如果要我写可能选三个方法 : : 1. 开两个thread. 中间开pipe : : 两边一起跑，这是最完美的做法。 : : 就跟unix like的command line pipe一样的行为 ↑我目前的解法 : : 2. producer写到ByteArrayOutputStream : : 写完把bytes拿出来放到ByteArrayInputStream去读 : : 免开thread. 也够快.. 但是缺点就是档案大吃太多memory : : 3. producer写到temp file : : consumer从temp file读 : : 免开thread.. 也不怕档案大 : : 但选择方案的时候我会有三个考量点要考量 : : a. 效率 : : b. 最大Memory使用量 (memory footprint) : : c. 程式码简单，流程单纯。 : : 如果你的效能是你很大的考量。 : : 而且你的档案有可能会很大。 : : 那我建议你选1的方案。也算是大多数情况最好的解。 : : 唯一的缺点就是流程复杂点，程式码比较难懂。 其实弄清楚那两个 pipe 类别之後，我觉得看起来很好懂 XD 或许跟我程式的流程有关，然後就是 Excel 档有四张试算表， 总列数 18,000 上下，栏数平均约 25 : : 退而求其次，如果今天你已经确定资料量不会太大 : : 也许2是最好解。简单，快速，易懂。 : : 如果效能不会是太大考量。 : : 也许你的程式你久久才跑一次这段程式 : : 而每次跑也只是0.1秒跟0.001秒的差别。 : : 那写档会是最简单，不吃memory的做法 我目前程式规则还有几次变动的可能，常需要重跑 : : 写程式本来很多都是trade off : : 你必须要有能力可以评估 : : 虽然效能差距1000倍 : : 但是你的程式在这边本来就不占0.01%的时间 : : 不是performance bottleneck : : 或是你的程式根本就久久才用一次这段code : : 那我们当然选择一个易懂不易出错很容易maintain的版本 相当认同 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 111.254.53.50 ※ 文章网址: http://webptt.com/cn.aspx?n=bbs/java/M.1398440084.A.847.html ※ 编辑: willy69wu31 (111.254.53.50), 04/25/2014 23:35:27 只有 1,456 KB，是 xlsx 格式 附带一提，里面有八九成资料必须存成 double ※ 编辑: willy69wu31 (111.254.53.50), 04/26/2014 00:03:56