插入USB热点后，简单的Java程序慢了100倍

Question

I have following Java program:

class Main {
    public static void main(String[] args) throws java.io.IOException {
        long start = System.nanoTime();
        java.io.File.createTempFile("java_test", ".txt").delete();
        System.out.println((System.nanoTime() - start ) / 1e9);
    }
}

Normally, it takes bout 63 miliseconds to execute:

$ java Main
0.06308555

But, once I connect Android phone as USB hotspot, it takes significantly longer. Depending on the machine anywhere from 3 to 40 seconds:

$ java Main
4.263285528

The strange thing is that nothing here is actually transferred over the network - plugged network adapters shouldn't matter.

I did a backtrace and it looks like majority of time is spent in NetworkInterface.getAll method:

"main" #1 prio=5 os_prio=0 tid=0x00000000023ae000 nid=0x142c runnable [0x000000000268d000]
   java.lang.Thread.State: RUNNABLE
        at java.net.NetworkInterface.getAll(Native Method)
        at java.net.NetworkInterface.getNetworkInterfaces(Unknown Source)
        at sun.security.provider.SeedGenerator.addNetworkAdapterInfo(Unknown Source)
        at sun.security.provider.SeedGenerator.access$000(Unknown Source)
        at sun.security.provider.SeedGenerator$1.run(Unknown Source)
        at sun.security.provider.SeedGenerator$1.run(Unknown Source)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.security.provider.SeedGenerator.getSystemEntropy(Unknown Source)
        at sun.security.provider.SecureRandom$SeederHolder.<clinit>(Unknown Source)
        at sun.security.provider.SecureRandom.engineNextBytes(Unknown Source)
        - locked <0x000000076afa2820> (a sun.security.provider.SecureRandom)
        at java.security.SecureRandom.nextBytes(Unknown Source)
        - locked <0x000000076af6bdc8> (a java.security.SecureRandom)
        at java.security.SecureRandom.next(Unknown Source)
        at java.util.Random.nextLong(Unknown Source)
        at java.io.File$TempDirectory.generateFile(Unknown Source)
        at java.io.File.createTempFile(Unknown Source)
        at java.io.File.createTempFile(Unknown Source)
        at Main.main(Main.java:4)

which, in turn, seems to spend most of the time in GetIfTable Windows API method:

Child-SP          RetAddr           Call Site
00000000`0257ed78 000007fe`fd7210ba ntdll!NtDeviceIoControlFile+0xa
00000000`0257ed80 000007fe`fd721252 nsi+0x10ba
00000000`0257ee20 000007fe`fd7211f9 nsi!NsiEnumerateObjectsAllParametersEx+0x2e
00000000`0257ee60 000007fe`fd7217b0 nsi!NsiEnumerateObjectsAllParameters+0xc9
00000000`0257ef00 000007fe`f9c7928d nsi!NsiAllocateAndGetTable+0x184
00000000`0257efd0 00000000`6f8c5a01 IPHLPAPI!GetIfTable+0xa9
00000000`0257f090 00000000`6f8c6980 net!Java_java_net_NetworkInterface_getMTU0+0x1a1
00000000`0257f150 00000000`6f8c6e57 net!Java_java_net_NetworkInterface_isP2P0_XP+0x88
00000000`0257f270 00000000`6f8c6058 net!Java_java_net_NetworkInterface_getAll_XP+0x23
00000000`0257f2a0 00000000`02867f54 net!Java_java_net_NetworkInterface_getAll+0x2c

GetIfTable seems to be the problematic function. I'm observing the same slowdown both in example program from: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365943(v=vs.85).aspx and with following snippet:

#include <iphlpapi.h>
#include <stdlib.h>

int main() {
    DWORD dwSize = sizeof(MIB_IFTABLE);
    MIB_IFTABLE *pIfTable = malloc(dwSize);
    GetIfTable(pIfTable, &dwSize, FALSE);
    pIfTable = malloc(dwSize);
    GetIfTable(pIfTable, &dwSize, FALSE);
    return 0;
}

How do I fix or workaround this problem? I can create temporary files on my own and avoid calling NetworkInterface.getNetworkInterfaces but SecureRandom is used all over Java standard library. Is there a way to force SecureRandom not to use GetIfTable?

Java version:

> java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

Windows version:

OS Name:                   Microsoft Windows 7 Professional
OS Version:                6.1.7601 Service Pack 1 Build 7601

Problematic network adapter:

Name    [00000020] Remote NDIS based Internet Sharing Device
Adapter Type    Ethernet 802.3
Product Type    Remote NDIS based Internet Sharing Device
Installed   Yes
PNP Device ID   USB\VID_0FCE&PID_71C4&MI_00\7&6BE3F3B&0&0000
Last Reset  8/14/2016 12:26 PM
Index   20
Service Name    usb_rndisx
IP Address  192.168.42.183, fe80::90ab:3786:4396:2870
IP Subnet   255.255.255.0, 64
Default IP Gateway  192.168.42.129
DHCP Enabled    Yes
DHCP Server 192.168.42.129
DHCP Lease Expires  8/14/2016 3:27 PM
DHCP Lease Obtained 8/14/2016 2:27 PM
MAC Address 02:18:61:77:7D:72
Driver  c:\windows\system32\drivers\usb8023x.sys (6.1.7600.16385, 19.50 KB (19,968 bytes), 7/14/2009 2:09 AM)

Answer 1

Default implementation of SecureRandom scans network interfaces as an additional source of system entropy. In order to avoid this, you need to register a custom java.security.Provider that contains a different implementation of SecureRandomSpi .

Fortunately, JDK for Windows already has a suitable SecureRandomSpi implementation that relies on Microsoft Crypto API: sun.security.mscapi.PRNG . Though this is non-public API, the class exists in all versions of OpenJDK and Oracle JDK from 1.6 to 9, and the fallback is available anyway.

There are two ways to register MS Crypto PRNG as the default SecureRandom algorithm.

1. From within the application by calling WindowsSecureRandom.register() at the very beginning.

import java.security.Provider;
import java.security.Security;

public class WindowsSecureRandom extends Provider {
    private static final String MSCAPI = "sun.security.mscapi.PRNG";

    private WindowsSecureRandom() {
        super("WindowsSecureRandom Provider", 1.0, null);
        putService(new Service(this, "SecureRandom", "Windows-PRNG", MSCAPI, null, null));
    }

    public static void register() {
        if (System.getProperty("os.name").contains("Windows")) {
            try {
                Class.forName(MSCAPI);
                Security.insertProviderAt(new WindowsSecureRandom(), 1);
            } catch (ClassNotFoundException e) {
                // Fallback to default implementation
            }
        }
    }
}

2. By reordering provider list in %JAVA_HOME%\\jre\\lib\\security\\java.security file.

security.provider.1=sun.security.mscapi.SunMSCAPI  <<<--- make it the first provider
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=sun.security.ec.SunEC
security.provider.5=com.sun.net.ssl.internal.ssl.Provider
...

I've verified that with either solutions SeedGenerator and NetworkInterface classes are no longer loaded.