警告:[/127.0.0.1:2293]远程主机强迫关闭了一个现有的连接。

Posted 2023-05-06

警告:[/127.0.0.1:2293]远程主机强迫关闭了一个现有的连接。
java.io.IOException:远程主机强迫关闭了一个现有的连接。
at sun.nio.ch.SocketDispatcher.read0<Native Method>
at sun.nio.ch.SocketDispatcher.read<Unknown Source>
at sun.nio.ch.IOUtil.readIntoNativeBuffer<Unknown Source>
at sun.nio.ch.IOUtil.read<Unknown Source>
at sun.nio.ch.SocketChannelImpl.read<Unknown Source>
at org.apache.mina.transport.socket.nio.SocketIoProcessor.read<SocketIoProcessor.java:218>
at org.apache.mina.transport.socket.nio.SocketIoProcessor.process<SocketIoProcessor.java:198>
at org.apache.mina.transport.socket.nio.SocketIoProcessor.access$400<SocketIoProcessor.java:45>
at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run<SocketIoProcessor.java:485>
at org.apache.mina.util.NamePreservingRunnable.run<NamePreservingRunnable.java:51>
at java.lang.Thread.run<Unknown Source>
请帮忙解释一下上面是什么意思？
@echo off
set CLASSPATH=.;dist\odinms.jar;dist\mina-core.jar;dist\slf4j-api.jar;dist\slf4j-jdk14.jar;dist\mysql-connector-java-bin.jar
java -Dnet.sf.odinms.recvops=recvops.properties -Dnet.sf.odinms.sendops=sendops.properties -Dnet.sf.odinms.wzpath=wz\ -Dnet.sf.odinms.channel.config=channel.properties -Djavax.net.ssl.keyStore=key.keystore -Djavax.net.ssl.keyStorePassword=passwd -Djavax.net.ssl.trustStore=key.keystore -Djavax.net.ssl.trustStorePassword=passwd net.sf.odinms.net.channel.ChannelServer
还有这个批处理文件，也帮忙解释下什么意思?
为什么会出现上面那个“警告:[/127.0.0.1:2293]远程主机强迫关闭了一个现有的连接。”？

127.0.0.1

这个IP代表的是你本机！至于“强迫关闭了一个现有的连接”

要么是中毒了要么就是你在下载文件2002年以后微软XPSP2引用了并发连接数限制的功能，默认的只有20个！但是现在除得盗版系统一般都破解提升了连接数好几倍。一般来说不会使这个原因！

再就是你说的问题不明确！其他我无法回答！ 参考技术A 1楼是2b 1楼是2b

Callgrind main() 包含成本远小于 100%

【中文标题】Callgrind main() 包含成本远小于 100%

【英文标题】：Callgrind main() inclusive cost much smaller than 100%

【发布时间】：2011-02-16 15:57:49

【问题描述】：

我分析了一些在 Linux 上运行的非常简单的 C++ 程序。所有这些的 main() 的包含成本远不是 100%，大约是 3.83%。我正确使用 callgrind 吗？我在下面粘贴了callgrind_annotate 和--inclusive=yes 的输出。

这个程序叫做堆，它进行简单的堆排序。我使用的命令是

valgrind --tool=callgrind ./heap

然后，我输入

callgrind_annotate --inclusive=yes callgrind.out.25434

输出：

`--------------------------------------------------------------------------------

Profile data file 'callgrind.out.25434' (creator: callgrind-3.6.0)

`--------------------------------------------------------------------------------

I1 cache:
D1 cache:
LL cache:
Timerange: Basic block 0 - 361578
Trigger: Program termination
Profiled target:  ./heap (PID 25434, part 1)
Events recorded:  Ir
Events shown:     Ir
Event sort order: Ir
Thresholds:       99
Include dirs:
User annotated:
Auto-annotation:  off

`--------------------------------------------------------------------------------

       Ir
`--------------------------------------------------------------------------------

2,552,558  PROGRAM TOTALS

`--------------------------------------------------------------------------------

       Ir  file:function

`--------------------------------------------------------------------------------

2,552,558  ???:0x00000810 [/lib/ld-2.7.so]

2,515,793  ???:0x00000a60 [/lib/ld-2.7.so]

2,515,219  ???:0x00015270 [/lib/ld-2.7.so]

2,514,780  ???:0x000021e0 [/lib/ld-2.7.so]

2,456,164  ???:0x0000b2f0 [/lib/ld-2.7.so]

2,256,719  ???:0x00009e40 [/lib/ld-2.7.so]

1,702,371  ???:0x00009ac0 [/lib/ld-2.7.so]

  657,883  ???:0x000098e0 [/lib/ld-2.7.so]

  367,045  ???:0x00017040 [/lib/ld-2.7.so]

   33,170  ???:0x080483e0 [/home/test/heap]

   33,036  ???:0x0000ce60 [/lib/ld-2.7.so]

   31,347  ???:0x0000e850 [/lib/ld-2.7.so]

   30,706  ???:(below main) [/lib/libc-2.7.so]

   30,071  ???:0x00008570 [/lib/ld-2.7.so]

   27,954  ???:0x0000f500 [/lib/ld-2.7.so]

   27,758  ???:0x0000ca30 [/lib/ld-2.7.so]

   21,366  ???:0x0001767b [/lib/ld-2.7.so]

【问题讨论】：

您的输出似乎至少有一些丢失。特别是，我没有看到任何包容性成本数据。你的程序运行需要多长时间？如果您安排它花费更长的时间（例如，堆排序更长的数组），包容性成本是否接近 100%？运行时在 main() 被调用之前所做的任何事情都不会被计算在内，因此如果 main() 所做的事情比（例如）加载动态库便宜得多，那么包含成本可能会低于 100%。绝对单位（比如毫秒）的不足是多少？

谢谢加雷斯！堆排序耗时不到 1 秒。我会让它运行更长的时间。我想确保我正确使用了 callgrind。由于在分析实际应用程序时，在我消除了由 callgrind 识别的一个大瓶颈（仅 47%）之后，总运行时间根本没有改变。

【参考方案1】：

main() 不是调用图中的***函数。 glibc 中有一个_start 函数，它会调用main()，它也会从main 中获取返回值。还有（对于动态链接的程序 = 几乎所有）一个 ELF 解释器，也称为动态链接器（运行时）：/lib/ld-linux.so（这个名称在 linux 中使用，在其他 Unix 中类似于 /lib /ld.so)。链接器将加载和初始化应用程序所需的所有动态库；在_start之前被操作系统调用。

main 之前做了什么？加载库（打开库文件，解析它的头文件，映射它，在内存=重定位处理中采用新位置的代码），以及它们的初始化（动态和静态链接的库都需要这个；注意 glibc=libc 也是库） .每个库都可能有一个代码，该代码将在库加载后立即启动（__attribute__((constructor)) 或全局对象的非平凡构造函数）。此外，glibc 可以注册一些函数在 main 之后运行（例如通过atexit()；如果 main 正常返回，它们将被 _start 调用），并且库可能具有全局对象的析构函数。

如果您的程序使用线程，则线程1..n 的顶部函数将不是主函数（每个线程都可以分离堆栈；来自main 的函数调用链存储在堆栈中 线程 0)。

在您的示例中，我们看到 /lib/ld-*.so，它是一个动态链接器。看来，您的应用程序执行时间太短而无法正确分析，并且它使用了大量动态库。