MessageDigest.digest抛出ArrayIndexOutOfBoundsExcepti

如下

public class Security 
{
	private MessageDigest md5;
	
	public void initMd5()
	{
		try 
		{
			md5 = MessageDigest.getInstance("MD5");
		} 
		catch (Exception e) 
		{
			e.printStackTrace();
		}
	}
	
	byte[] getMd5Digest(byte[] context,int start,int length)
	{
		byte[] bb = new byte[length];
		md5.update(context);
		bb = md5.digest();
		return bb;
	}
}

实际应用中也如上面的代码，在执行的时候抛出
java.lang.ArrayIndexOutOfBoundsException
        at java.lang.System.arraycopy(Native Method)
        at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:102)
        at sun.security.provider.MD5.implDigest(MD5.java:95)
        at sun.security.provider.DigestBase.engineDigest(DigestBase.java:161)
        at sun.security.provider.DigestBase.engineDigest(DigestBase.java:140)
        at java.security.MessageDigest$Delegate.engineDigest(MessageDigest.java:531)
        at java.security.MessageDigest.digest(MessageDigest.java:309)
，提示是在执行md5.digest()的时候抛出的异常，执行update也没有涉及传入byte数组长度；再网上查找说是，MessageDigest不是线程安全，做同步操作即可以，但是自己模拟多线程执行不能抛出这样的异常。上面问题不是必然重现的，请问各位是否也遇到过同样的问题？
谢谢！

与这个描述的问题基本一样
Under heavy load I have been having problems with generateBranchId() throwing the following exception:

java.lang.ArrayIndexOutOfBoundsException
        at java.lang.System.arraycopy(Native Method)
at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:102)
        at sun.security.provider.MD5.implDigest(MD5.java:100)
at sun.security.provider.DigestBase.engineDigest(DigestBase.java:161) at sun.security.provider.DigestBase.engineDigest(DigestBase.java:140) at java.security.MessageDigest$Delegate.engineDigest(MessageDigest.java:531) at java.security.MessageDigest.digest(MessageDigest.java:309) at java.security.MessageDigest.digest(MessageDigest.java:355) at gov.nist.javax.sip.Utils.generateBranchId(Utils.java:151) at gov.nist.javax.sip.SipProviderImpl.getNewClientTransaction(SipProviderImpl.java:349)
        at uas.Server.processAck(Server.java:75)
        at uas.Server.processRequest(Server.java:54)
at gov.nist.javax.sip.EventScanner.deliverEvent(EventScanner.java:219) at gov.nist.javax.sip.SipProviderImpl.handleEvent(SipProviderImpl.java:148) at gov.nist.javax.sip.DialogFilter.processRequest(DialogFilter.java:902) at gov.nist.javax.sip.stack.SIPServerTransaction.processRequest(SIPServerTransaction.java:758) at gov.nist.javax.sip.stack.UDPMessageChannel.run(UDPMessageChannel.java:403)
        at java.lang.Thread.run(Thread.java:613)

By declaring the method to be "synchronized", the problem appears to have been resolved. Here is the diff:

Index: Utils.java

但模拟了多线程的情况不能出现上述异常，所以感觉多线程应该不是导致这个异常的原因！

这是在网上搜到的
We're using the java client library from Greg Whalin (
http://www.whalin.com/memcached/).

When using the consistent hash (md5-based) under heavy load we're seeing
ArrayIndexOutOfBoundsExceptions,

java.lang.ArrayIndexOutOfBoundsException
        at java.lang.System.arraycopy(Native Method)
        at sun.security.provider.DigestBase.engineUpdate(DigestBase.java:102)
        at sun.security.provider.MD5.implDigest(MD5.java:100)
        at sun.security.provider.DigestBase.engineDigest(DigestBase.java:161)
        at sun.security.provider.DigestBase.engineDigest(DigestBase.java:140)
        at java.security.MessageDigest$Delegate.engineDigest(MessageDigest.java:531)
        at java.security.MessageDigest.digest(MessageDigest.java:309)
        at com.danga.MemCached.SockIOPool.md5HashingAlg(SockIOPool.java:522)
        at com.danga.MemCached.SockIOPool.getHash(SockIOPool.java:547)
        at com.danga.MemCached.SockIOPool.getBucket(SockIOPool.java:557)
        at com.danga.MemCached.SockIOPool.getSock(SockIOPool.java:918)
        at com.danga.MemCached.MemCachedClient.get(MemCachedClient.java:1266)

Looks like the culprit is the static MessageDigest instance on line 140 of SockIOPool.java.
The MessageDigest instance is statefull, and I don't see any indication  that it is thread-safe.

Has anyone else encountered this problem?

My plan is to switch to a stateless FNV hashing implementation.



Yup, message digest is stateful and is not thread-safe and a new instance needs to be instantiated for every execution.  Definitely a bug if a message digest instance is being used by multiple threads concurrently without synchronization.