【问题标题】:Is it ok to be calling reset() on an ObjectOutputStream very frequently?可以非常频繁地在 ObjectOutputStream 上调用 reset() 吗?
【发布时间】:2014-03-08 03:09:45
【问题描述】:

我在某个地方读到了让我不确定的地方,并正在寻找另一种方法。过于频繁地调用reset() 是否会导致网络紧张,或者对此没有必要?

我正在使用 TCP 通过 ObjectOutputStream 发送对象。对象值在再次写入之前已更改。现在相同的对象但包含不同的值,没有reset() 它重新发送在它之前发送的缓存对象的引用,读取它没有变化。由于这种压力,我不确定使用reset() 是否是一个好主意。我应该寻找其他方法吗?

示例代码如下:

Socket socket = new Socket(ip, port);

BufferedOutputStream bos = new BufferedOutputStream(socket.getOutputStream());
ObjectOutputStream oos = new ObjectOutputStream(bos);

while(true){
    oos.writeObject(object);
    oos.flush();
    oos.reset();

    object.x++;
}

【问题讨论】:

  • 我会在 flush() 之前调用 reset() 作为微优化,但您可以在每个对象上调用它。
  • @PeterLawrey 为什么?而不是事后调用它?
  • @EJP 如果在 flush() 之前 reset(),reset() 会立即发送,另一端可以删除对对象的引用。如果你先flush(),然后reset(),另一端可能会保持对象一段时间,这是一种浪费,因为它接下来要做的就是丢弃它。

标签: java tcp reset outputstream


【解决方案1】:

是否过于频繁地调用 reset() 会导致网络紧张

与什么相比?如果需要重新设置,是因为需要用新值传输之前传输的对象。如果您不需要这样做,请不要调用它。如果确实需要,网络开销与功能需求无关。

还是没有必要?

诶?请翻译?

我正在使用 TCP 通过 ObjectOutputStream 发送对象。对象值在再次写入之前已更改

因此您需要调用 reset() 或使用 writeUnshared()。

现在是同一个对象,但包含不同的值,没有 reset(),它会重新发送在它之前发送的缓存对象的引用,读取它没有变化。

正确。所以你不能那样做。

由于这种压力,我不确定使用 reset() 是否是个好主意。

什么品种?唯一的“压力”是您正在传输对象的新值,而您的功能要求要求您必须这样做。所以你别无选择。

我应该寻找其他方法吗?

没有别的办法。要么你必须传输对象的新值,要么你不需要。如果这样做,所有解决方案基本上都是等效的。如果你不这样做,就不要。

【讨论】:

  • 这种操作不需要?就像也许我可以设置一个 UDP 连接来代替更新原语并使用字节来完成这一切。这样做也会删除reset()。但是,如果唯一的问题是我不确定,为什么要避免它。我试过writeUnshared() 它仍然没有在另一端得到更新。压力是我担心的。我认为每次重置就像关闭和打开连接一样。在如此短的循环中,这似乎并不正确。无论如何,感谢您澄清这一点,您回答了我的问题。
  • “如果唯一的问题是我不确定,为什么要避免它?”不是一个逻辑问题。不确定性不是避免或不避免它的理由。我回答后你没有任何不确定的理由,除非我说了一些你不明白的话,你应该问我。重置不会关闭并重新打开连接。它只是清除本地缓存并向对等方发送几个字节告诉他也这样做。 writeUnshared() 方法仍然共享从正在写入的对象引用的对象:它仅“取消共享”该对象本身:请参阅 Javadoc。
  • 那时我可能会冒不必要的风险。因此,与其寻找解决方法,我更愿意看看它是否可以以这种方式使用。更多地了解正在发生的事情将有助于减轻以后出现与此相关的未知错误的担忧。我足够了解我现在在做什么。经过您的澄清和一些研究。感谢您提供更详细的信息。
猜你喜欢
  • 1970-01-01
  • 2019-05-30
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-01-11
  • 2018-11-25
  • 1970-01-01
相关资源
最近更新 更多