java - 回收 DatagramPacket 对象安全吗？

Question

问题:

假设您的传输速度高达 10 MB/s，那么回收 DatagramPacket 对象(而不是每次发送数据包时创建一个新对象)是否是一个好主意？

故事:

我正在创建一个 LAN 文件同步应用程序，有时可以处理超过 30 GB 的文件。文件同步应用程序将通过 100Mbit 有线 LAN 传输文件。我已经有了一个防丢包系统(运行完美)。

该程序运行良好，但占用了大约 10% 的 CPU 使用率，而且由于这是一个后台应用程序，这对我来说太多了。理想情况下，最高值约为 3%。

在分析时，我发现垃圾收集器正在变得疯狂，每隔几秒就会激活一次。我知道对象创建(当大量完成时)对于 Java 来说会很繁重，所以现在我正在尝试回收尽可能多的对象和数组。每个包含文件数据的数据包大小为 1450 字节，这意味着以 10 MB/s 的速度传输大约每秒 7,200 个数据包。我决定开始回收这些数据包(即，当发送数据包时，DatagramPacket 对象将添加到列表中，5 秒后，DatagramPacket 可以重新使用) 。当重复使用DatagramPacket时，DatagramPacket.setData()方法用于分配要发送的数据。

除了发送包含文件数据的数据包之外，我还大约每秒发送一些小数据包来尝试确定连接的 ping。这些 ping 数据包的大小为 10 字节。

错误:

使用 DatagramPacket 回收功能测试我的应用程序大约 30 分钟后，开始出现奇怪的错误。有一次，正在传输的文件被损坏了，而其他时候，我却得到了一些我无法理解的东西……下面是我类(class)的一些代码。 整数length只能通过applyData()方法设置。

public class PacketToSend {

    private int length;
    private DatagramPacket packet;

    ...

    public void applyData(byte[] newData) {
        try {
            length = newData.length;
            packet.setData(newData, 0, length);
        } catch(java.lang.IllegalArgumentException e) {
            System.out.println("Arraylength = "+newData.length);
            System.out.println("length value = "+length);
        }
    }

    ...

}

每次测试大约20-40分钟后，我得到一个IllegalArgumentException，告诉我newData的大小是10，并且length的值 是 1450，因此说明该长度是非法的。这怎么可能？除了在此方法中之外，变量 length 不会在其他任何地方修改，并且在调用 setData() 之前设置!就好像 DatagramPacket 随机切换为发送 ping 数据...

仅当我启用 DatagramPacket 回收功能时才会出现这些错误。

请注意，数据包发送后，会被放入列表中，并会等待 5 秒，然后才能再次使用。我想知道操作系统是否以某种方式介入这些数据包，或者也许某些 native 代码正在操纵数据。

我的程序中只有一个线程发送数据包，因此这不是线程或同步问题。

因此我的问题是:回收 DatagramPacket 对象而不是每次发送数据包时创建一个新对象是一个好主意吗？或者我是在玩火，还是我真的不该管的事？

尝试修复:

• 我在调用后放置了 length = newData.length;setData(newData, 0, newData.length);，这阻止了IllegalArgumentException 但我仍然遇到其他错误，例如作为连接丢失。不管怎样，根据上面提到的错误据我对 Java 的了解，这种情况根本不应该发生，所以我认为还有其他因素在起作用。

Answer 1

Is it safe to recycle DatagramPacket objects?

据我所知或可以确定，重用 DatagramPacket 实例本身并没有什么不安全的地方。

另一方面，您描述的错误只有在两个或多个线程之间共享实例时才有意义，并且在没有适当同步的情况下从多个线程访问共享对象绝对是不安全的。再多的等待也无法替代同步，因此在重用之前施加 5 秒延迟的策略可能会适得其反——它不能保证正确的操作，但可能会导致您的程序维护比实际需要更多的 Activity 对象。

由于没有您的程序架构的详细信息，我们只能笼统地谈论您可以采取哪些措施来解决这种情况。在最一般的层面上，替代方案是避免在线程之间共享对象并以线程安全的方式访问共享对象。然而，任何线程安全对象共享机制都会带来相对较大的开销，而且我倾向于认为在一个文件传输过程中执行 2000 万个线程安全操作的成本太高，无法接受。因此，最好的选择是避免共享对象。

在每次需要时创建新的 DatagramPacket 并且不允许它们转义创建它们的线程是实现这一目标的一种方法。由于这会导致过多的 GC，因此下一个逻辑步骤可能是维护可重用数据包的每线程队列。您可以使用 ThreadLocal 来实现此目的，但如果每个文件传输都由单个线程管理，那么您也可以考虑使用每个文件队列。无论哪种方式，也要小心其他共享，例如 DatagramPacket 携带的数据缓冲区数组(很可能是您可以重用的其他东西)。

此外，如果您小心不要在线程之间共享数据，那么您应该能够在没有重用延迟的情况下这样做。事实上，每个线程可能不需要多个 DatagramPacket 和一个缓冲区数组。这可以使您的代码不仅更高效，而且更简单。