数据库oracle connection reset 产生原因,jdbc连接oracle Connection reset异常

最近做了一次服务器迁移， 迁完新服务器后，应用在启动时，连接数据库发生异常java.net.SocketException: Connection reset. JDBC驱动是11g。

异常 Connection reset

Caused by: java.net.SocketException: Connection reset

at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:113) ~[?:1.8.0_65]

at java.net.SocketOutputStream.write(SocketOutputStream.java:153) ~[?:1.8.0_65]

at oracle.net.ns.DataPacket.send(DataPacket.java:210) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.net.ns.NetOutputStream.flush(NetOutputStream.java:230) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.net.ns.NetInputStream.getNextPacket(NetInputStream.java:312) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.net.ns.NetInputStream.read(NetInputStream.java:260) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.net.ns.NetInputStream.read(NetInputStream.java:185) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.net.ns.NetInputStream.read(NetInputStream.java:102) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.jdbc.driver.T4CSocketInputStreamWrapper.readNextPacket(T4CSocketInputStreamWrapper.java:124) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.jdbc.driver.T4CSocketInputStreamWrapper.read(T4CSocketInputStreamWrapper.java:80) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.jdbc.driver.T4CMAREngine.unmarshalUB1(T4CMAREngine.java:1137) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:290) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:192) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.jdbc.driver.T4CTTIoauthenticate.doOSESSKEY(T4CTTIoauthenticate.java:404) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:385) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:546) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.jdbc.driver.T4CConnection.(T4CConnection.java:236) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:521) ~[ojdbc-6-11.2.0.3.jar:11.2.0.3.0]

java.net.SocketException: Connection reset 异常的发生，一般是因为连接的一方关闭了连接，而另一方依然从连接从读或写，就会抛出该异常。

尝试重启应用在多次后，又能正常启动并连上数据库。甚是奇怪。启动的时候，观察日志输出，在初始化连接池的时候卡顿了好几分钟，然后就抛出以上的异常了。谷歌了下，有人说是因为oracle在登录的时候，需要调用那个SecureRandom.nextBytes，造成了长时间挂起，导致连接超时被关闭了。

间隔时间jstack 了进程几次，发现SecureRandom.nextBytes 确实长时间挂起了，没有返回。

"localhost-startStop-1" #20 daemon prio=5 os_prio=0 tid=0x00007f0cdc001800 nid=0x4e64 runnable [0x00007f0d64119000]

java.lang.Thread.State: RUNNABLE

at java.io.FileInputStream.readBytes(Native Method)

at java.io.FileInputStream.read(FileInputStream.java:255)

at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:539)

at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:144)

at sun.security.provider.SecureRandom$SeederHolder.(SecureRandom.java:203)

at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:221)

- locked <0x000000077c2c8850> (a sun.security.provider.SecureRandom)

at java.security.SecureRandom.nextBytes(SecureRandom.java:468)

- locked <0x000000077c2c8b70> (a java.security.SecureRandom)

at oracle.security.o5logon.O5Logon.a(Unknown Source)

at oracle.security.o5logon.O5Logon.(Unknown Source)

at oracle.jdbc.driver.T4CTTIoauthenticate.(T4CTTIoauthenticate.java:566)

at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:370)

at oracle.jdbc.driver.PhysicalConnection.(PhysicalConnection.java:546)

at oracle.jdbc.driver.T4CConnection.(T4CConnection.java:236)

at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:32)

at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:521)

解决方法：

增加启动参数

-Djava.security.egd=file:/dev/../dev/urandom

延伸 random 和 urandom

/dev/random 和/dev/urandom 是linux 提供用于产生随机数的设备。他们产生随机数的原理是利用当前系统的熵池来计算出固定一定数量的随机比特，然后将这些比特作为字节流返回。熵池就是当前系统的环境噪音，熵指的是一个系统的混乱程度，系统噪音可以通过很多参数来评估，如内存的使用，文件的使用量，不同类型的进程数量等等。如果当前环境噪音变化的不是很剧烈或者当前环境噪音很小，比如刚开机的时候，而当前需要大量的随机比特，这时产生的随机数的随机效果就不是很好了。

/dev/random 在不能产生新的随机数时会阻塞程序直到新的环境噪音被收集，而/dev/urandom不会阻塞，它会重用已有的熵池来产生新的随机数，当然它生产的随机数效果就不太好。

SecureRandom默认使用/dev/random来产生数据数。

在SecureRandom 的javadoc 并提到了在读取/dev/random 可能发生的阻塞。

Depending on the implementation, the generateSeed and nextBytes methods may block as entropy is being gathered, for example, if they need to read from /dev/random on various unix-like operating systems.