ファイル ハッシュ アルゴリズムを最適化して、可能な限りパフォーマンスを低下させようと、かなりの時間を費やしました。
以前の SO スレッドを参照してください。
FileChannel ByteBuffer とハッシュ ファイル
Java NIO
ネイティブのパフォーマンスを向上させるために (JVM にバッファを持ち込むのではなく、システム内にバッファを保持することによって)使用することが何度か推奨されました。ただし、私のNIOコードは、ベンチマークでかなり遅く実行されます(結果を歪める可能性のあるOS /ドライブの「魔法」を無効にするために、各アルゴリズムで同じファイルを何度もハッシュします。
私は今、同じことをする2つの方法を持っています:
This one runs faster almost every time:
/**
* Gets Hash of file.
*
* @param file String path + filename of file to get hash.
* @param hashAlgo Hash algorithm to use. <br/>
* Supported algorithms are: <br/>
* MD2, MD5 <br/>
* SHA-1 <br/>
* SHA-256, SHA-384, SHA-512
* @param BUFFER Buffer size in bytes. Recommended to stay in<br/>
* multiples of 2 such as 1024, 2048, <br/>
* 4096, 8192, 16384, 32768, 65536, etc.
* @return String value of hash. (Variable length dependent on hash algorithm used)
* @throws IOException If file is invalid.
* @throws HashTypeException If no supported or valid hash algorithm was found.
*/
public String getHash(String file, String hashAlgo, int BUFFER) throws IOException, HasherException {
StringBuffer hexString = null;
try {
MessageDigest md = MessageDigest.getInstance(validateHashType(hashAlgo));
FileInputStream fis = new FileInputStream(file);
byte[] dataBytes = new byte[BUFFER];
int nread = 0;
while ((nread = fis.read(dataBytes)) != -1) {
md.update(dataBytes, 0, nread);
}
fis.close();
byte[] mdbytes = md.digest();
hexString = new StringBuffer();
for (int i = 0; i < mdbytes.length; i++) {
hexString.append(Integer.toHexString((0xFF & mdbytes[i])));
}
return hexString.toString();
} catch (NoSuchAlgorithmException | HasherException e) {
throw new HasherException("Unsuppored Hash Algorithm.", e);
}
}
My Java NIO method that runs considerably slower most of the time:
/**
* Gets Hash of file using java.nio File Channels and ByteBuffer
* <br/>for native system calls where possible. This may improve <br/>
* performance in some circumstances.
*
* @param fileStr String path + filename of file to get hash.
* @param hashAlgo Hash algorithm to use. <br/>
* Supported algorithms are: <br/>
* MD2, MD5 <br/>
* SHA-1 <br/>
* SHA-256, SHA-384, SHA-512
* @param BUFFER Buffer size in bytes. Recommended to stay in<br/>
* multiples of 2 such as 1024, 2048, <br/>
* 4096, 8192, 16384, 32768, 65536, etc.
* @return String value of hash. (Variable length dependent on hash algorithm used)
* @throws IOException If file is invalid.
* @throws HashTypeException If no supported or valid hash algorithm was found.
*/
public String getHashNIO(String fileStr, String hashAlgo, int BUFFER) throws IOException, HasherException {
File file = new File(fileStr);
MessageDigest md = null;
FileInputStream fis = null;
FileChannel fc = null;
ByteBuffer bbf = null;
StringBuilder hexString = null;
try {
md = MessageDigest.getInstance(hashAlgo);
fis = new FileInputStream(file);
fc = fis.getChannel();
bbf = ByteBuffer.allocateDirect(BUFFER); // allocation in bytes - 1024, 2048, 4096, 8192
int b;
b = fc.read(bbf);
while ((b != -1) && (b != 0)) {
bbf.flip();
byte[] bytes = new byte[b];
bbf.get(bytes);
md.update(bytes, 0, b);
bbf.clear();
b = fc.read(bbf);
}
fis.close();
byte[] mdbytes = md.digest();
hexString = new StringBuilder();
for (int i = 0; i < mdbytes.length; i++) {
hexString.append(Integer.toHexString((0xFF & mdbytes[i])));
}
return hexString.toString();
} catch (NoSuchAlgorithmException e) {
throw new HasherException("Unsupported Hash Algorithm.", e);
}
}
私の考えでは、Java NIO
ネイティブ システム コールなどを使用して、システム内および JVM の外で処理とストレージ (バッファ) を保持しようとする試みです。これにより、(理論的には) プログラムが JVM とシステム。理論的には、これはより高速になるはずです...しかし、おそらく私MessageDigest
はJVMにバッファを強制的に取り込み、ネイティブバッファ/システムコールがもたらすパフォーマンスの向上を無効にしますか? 私はこの論理で正しいですか、それとも間違っていますか?
Please help me understand why Java NIO is not better in this scenario.