HashMap<String,Double> 的格式错误的二进制序列化

Question

我编写了一些代码来序列化HashMap<String,Double>，方法是迭代条目并序列化每个条目，而不是使用ObjectOutputStream.readObject()。原因只是效率：生成的文件更小，读写速度更快（例如，23 MB 需要 0.6 秒，而 29 MB 需要 9.9 秒）。

这是我为序列化所做的：

ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("test.bin"));
oos.writeInt(map.size()); // write size of the map
for (Map.Entry<String, Double> entry : map.entrySet()) { // iterate entries
    System.out.println("writing ("+ entry.getKey() +","+ entry.getValue() +")");
    byte[] bytes = entry.getKey().getBytes();
    oos.writeInt(bytes.length); // length of key string
    oos.write(bytes); // key string bytes
    oos.writeDouble(entry.getValue()); // value
}
oos.close();

如您所见，我为每个键 String 获取了 byte 数组，序列化其长度，然后序列化数组本身。这就是我为反序列化所做的：

ObjectInputStream ois = new ObjectInputStream(new FileInputStream("test.bin"));
int size = ois.readInt(); // read size of the map
HashMap<String, Double> newMap = new HashMap<>(size);
for (int i = 0; i < size; i++) { // iterate entries
    int length = ois.readInt(); // length of key string
    byte[] bytes = new byte[length];
    ois.read(bytes); // key string bytes
    String key = new String(bytes);
    double value = ois.readDouble(); // value
    newMap.put(key, value);
    System.out.println("read ("+ key +","+ value +")");
}

问题是在某些时候密钥没有正确序列化。我一直在调试到可以看到 ois.read(bytes) 读取 8 个字节而不是预期的 16 个字节，因此密钥 String 的格式不正确，double 值是使用最后 8 个字节读取的尚未读取的密钥中的字节。最后，异常无处不在。

使用下面的示例数据，输出在某些时候会是这样的：

read (2010-00-056.html,12154.250518054876)
read (2010-00-        ,1.4007397428546247E-76)
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
        at ti.Test.main(Test.java:82)

问题可以在序列化文件中看到（应该是2010-00-008.html）：

在String 键之间添加两个字节。有关更多信息，请参阅MxyL's answer。所以这一切都归结为：为什么要添加这两个字节，为什么readFully 可以正常工作？

为什么String 没有正确（反）序列化？可能是对固定块大小的某种填充或类似的东西？ 在寻找效率时有没有更好的方法来手动序列化String？我期待某种writeString和readString，但似乎Java的ObjectStream中没有这样的东西.

我一直在尝试使用缓冲流以防万一那里出现问题，明确说明要写入和读取多少字节，使用不同的编码，但没有运气。

这是重现问题的一些示例数据：

HashMap<String, Double> map = new HashMap<String, Double>();
map.put("2010-00-027.html",21732.994621513037); map.put("2010-00-020.html",3466.5169348296736); map.put("2010-00-051.html",12528.648992702407); map.put("2010-00-062.html",3354.8950010256385);
map.put("2010-00-024.html",10295.095511718278); map.put("2010-00-052.html",5381.513344679818);  map.put("2010-00-007.html",16466.33813960735);  map.put("2010-00-017.html",9484.969198176652);
map.put("2010-00-054.html",15423.873112634772); map.put("2010-00-022.html",8123.842752870753);  map.put("2010-00-033.html",21238.496665104063); map.put("2010-00-028.html",7578.792651786424);
map.put("2010-00-048.html",3566.4118233046393); map.put("2010-00-040.html",2681.0799941861724); map.put("2010-00-049.html",14308.090890746222); map.put("2010-00-058.html",5911.342406606804);
map.put("2010-00-045.html",2284.118716145881);  map.put("2010-00-031.html",2859.565771680721);  map.put("2010-00-046.html",4555.187022907964);  map.put("2010-00-036.html",8479.709295569426);
map.put("2010-00-061.html",846.8292195815125);  map.put("2010-00-023.html",14108.644025417952); map.put("2010-00-041.html",22686.232732684934); map.put("2010-00-025.html",9513.539663409734);
map.put("2010-00-012.html",459.6427911376829);  map.put("2010-00-005.html",0.0);    map.put("2010-00-013.html",2646.403220496738);  map.put("2010-00-065.html",5808.86423609936);
map.put("2010-00-056.html",12154.250518054876); map.put("2010-00-008.html",10811.15198506469);  map.put("2010-00-042.html",9271.006516004005);  map.put("2010-00-000.html",4387.4162586468965);
map.put("2010-00-059.html",4456.211623469774);  map.put("2010-00-055.html",3534.7511584735325); map.put("2010-00-057.html",8745.640098512009);  map.put("2010-00-032.html",4993.295735075575);
map.put("2010-00-021.html",3852.5805998017922); map.put("2010-00-043.html",4108.020033536286);  map.put("2010-00-053.html",2.2446400279239946); map.put("2010-00-030.html",17853.541210836203);

Answer 1

ois.read(bytes); // key string bytes

将此更改为使用 readFully()。您假设读取填充了缓冲区。它没有义务传输超过一个字节。

求效率的时候有没有更好的手动序列化String的方法？

有 writeUTF() 和 readUTF() 对。

您应该注意，通过调用 getBytes() 您正在引入平台依赖项。您应该在此处和重构字符串时指定字符集。

Answer 2

这里有两件事需要注意

首先，如果您取出示例数据中的最后 4 个条目，则不会发生错误。也就是说，这两个字节没有被错误地相加。很奇怪。

其次，如果您在十六进制编辑器中打开文件，并向下滚动到出现两个额外字节的条目，您将看到它以一个 4 字节整数开头，正确值为 16（保留在注意这是大端）。然后你会看到你的字符串有两个额外的字节，然后是与之关联的双字节。

现在，奇怪的是 Java 是如何读取这些字节的。首先，它按照您的指示读取字符串的长度。然后它尝试读取 16 个字节......但在这里它似乎未能读取 16 个字节，因为您的打印语句显示

read (2010-00-,1.3980409401811577E-76))

现在将光标放在这两个奇怪的字节之后，你会看到这个

从字符串的起始位置到当前指针所在的位置，似乎只读取了 10 个字节。

此外，当我尝试从我的 IDE 控制台复制该行时，它只是粘贴了

read (2010-00-

通常当一个字符串突然在我的复制粘贴中结束时，我通常会怀疑是空字节。看看我的剪贴板，确实，字节似乎没有被完全读入缓冲区：

好吧，看起来 Java 只设法读取了 10 个字节并继续前进，这解释了后面的字符串和数字。

所以看起来当你read 并传入一个缓冲区时，它并没有被完全填满。工具提示本身甚至有一条建议告诉我使用readFully！

所以做了一些测试，我继续改变

ois.read(bytes); // key string bytes

到

ois.readFully(bytes, 0, length); // key string bytes

无论出于何种原因，这都有效。

read (2010-00-013.html,2646.403220496738)
read (2010-00-005.html,0.0)
read (2010-00-056.html,12154.250518054876)
read (2010-00-008.html,10811.15198506469)
read (2010-00-042.html,9271.006516004005)
read (2010-00-000.html,4387.4162586468965)  // where it was failing before
read (2010-00-059.html,4456.211623469774)

问题

现在，它实际工作的事实是一个问题。 为什么有效？很明显，您的字符串之间有两个额外的字节（导致它的长度为 18，而不是 16）。文件并没有改变什么的。

确实，当我手动编辑文件使其只有三个条目时，我指出只有两个，这是我得到的输出：

read (2010-00-056.html,12154.250518054876)
read (2010-00-wd008.ht,1.2466701288348126E219)

这是我对 18 字节字符串的期望（好吧，也许不是 wd，我期望 w,），但您指定只有 16 个。您应该同意使用 @987654335 的事实@ 确实有效，很奇怪。

所以有几个谜团

1. 为什么要添加这两个额外的字节
2. 为什么在您删除最后 4 个条目（或更多，如果需要）时没有添加它们
3. 为什么使用readFully 有效，而其他一切都不变？

不幸的是，这个答案没有回答你的问题，而且我现在也很困惑，不仅是你提出的问题，还有我所看到的行为。

Answer 3

ObjectOutputStream 首先写入 STREAM_MAGIC(0xaced)，然后写入 STREAM_VERSION(5)，然后写入 TC_BLOCKDATALONG (0x7A)，然后写入块大小 (1024)，对于最后一个块，如果长度小于 255，则写入 TC_BLOCKDATA (0x77) 和块大小(最后一个区块的长度)

所以当 ObjectOutputStream 使用 readFully 时，它首先将数据读取到跳过 STREAM_MAGIC、STREAM_VERSION 的缓冲区，然后对于每个块，读取块大小以获取大小，然后将所有大小数据读取到缓冲区

Answer 4

ObjectInputStream#read 不保证它会读取 buffer.length() 字节数。当读取发生在当前预读缓冲区块的边缘时，它只会返回缓冲区中剩余的字节数。应该这样写。

        int offset=0;
        while(offset<length) {
            int cnt=ois.read(bytes,offset, length-offset); // key string bytes
            offset+=cnt;
        }