最近在研讀Mina框架的原始碼，剛好手頭上有專案就直接用上了。直接進入正題……

    對Mina有點了解的人都知道，Mina中有一條FilterChain，我們可以向其中加入Filter實現鏈式處理。從原始碼看來，多數Filter（如ProtocolCodecFilter）在使用過程只允許有一個例項。若FilterChain中存在多個相同的例項，則有可能出現各種莫明其妙的問題，這些問題往往是超出你預料之外的，而且除錯起來比較困難，除非你熟知Mina整個框架。究其原因，主要是在AttributeKey的問題，例：

public class ProtocolCodecFilter extends IoFilterAdapter {
    /** A logger for this class */
    private static final Logger LOGGER = LoggerFactory.getLogger(ProtocolCodecFilter.class);

    private static final Class<?>[] EMPTY_PARAMS = new Class[0];

    private static final IoBuffer EMPTY_BUFFER = IoBuffer.wrap(new byte[0]);

    private final AttributeKey ENCODER = new AttributeKey(ProtocolCodecFilter.class, "encoder");

    private final AttributeKey DECODER = new AttributeKey(ProtocolCodecFilter.class, "decoder");

    private final AttributeKey DECODER_OUT = new AttributeKey(ProtocolCodecFilter.class, "decoderOut");

    private final AttributeKey ENCODER_OUT = new AttributeKey(ProtocolCodecFilter.class, "encoderOut");
	
	...
	private ProtocolDecoderOutput getDecoderOut(IoSession session, NextFilter nextFilter) {
        ProtocolDecoderOutput out = (ProtocolDecoderOutput) session.getAttribute(DECODER_OUT);

        if (out == null) {
            // Create a new instance, and stores it into the session
            out = new ProtocolDecoderOutputImpl();
            session.setAttribute(DECODER_OUT, out);
        }

        return out;
    }
	...
}
 

    假設有兩個ProtocolCodecFilter例項，那麼同一時刻它們在各自的例項中AttributeKey其實是一樣的，即如果通過

ProtocolDecoderOutput out = (ProtocolDecoderOutput) session.getAttribute(DECODER_OUT);

它們獲取的例項是一樣的。因此，也就造成兩個例項中的ProtocolCodecOutput產生相互干擾的情況。

    我們再來看看為什麼兩個例項中的AttributeKey為什麼會是一樣的。

package org.apache.mina.core.session;

import java.io.Serializable;

/**
 * Creates a Key from a class name and an attribute name. The resulting Key will
 * be stored in the session Map.<br>
 * For instance, we can create a 'processor' AttributeKey this way :
 * 
 * <pre>
 * private static final AttributeKey PROCESSOR = new AttributeKey(
 * 	SimpleIoProcessorPool.class, "processor");
 * </pre>
 * 
 * This will create the <b>
 
[email protected]</b> key
 * which will be stored in the session map.<br>
 * Such an attributeKey is mainly useful for debug purposes.
 * 
 * @author <a href="http://mina.apache.org">Apache MINA Project</a>
 */
public final class AttributeKey implements Serializable {
    /** The serial version UID */
    private static final long serialVersionUID = -583377473376683096L;

    /** The attribute's name */
    private final String name;

    public AttributeKey(Class<?> source, String name) {
        this.name = source.getName() + '.' + name + '@' + Integer.toHexString(this.hashCode());
    }

    @Override
    public String toString() {
        return name;
    }

    @Override
    public int hashCode() {
        int h = 17 * 37 + ((name == null) ? 0 : name.hashCode());
        return h;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        }

        if (!(obj instanceof AttributeKey)) {
            return false;
        }

        AttributeKey other = (AttributeKey) obj;

        return name.equals(other.name);
    }
}
 

    session.getAttrubute(...) 中儲存<KEY, VALUE>對的其實是

private static class DefaultIoSessionAttributeMap implements IoSessionAttributeMap {
        private final ConcurrentHashMap<Object, Object> attributes = new ConcurrentHashMap<Object, Object>(4);
		...
}

是一個ConcurrentHashMap。因此，它是通過KEY的hashCode去尋找物件，上述兩個例項是一樣的，事實上間接說明了它們的hashCode()返回的是一樣的值。

    我們看到AttributeKey的hashCode()函式，唯一不一樣的地方就只能是name，name是String型別的，其hashCode()計算方法如下：

Open Declaration int java.lang.String.hashCode()


Returns a hash code for this string. The hash code for a String object is computed as 

 s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
 
using int arithmetic, where s[i] is the ith character of the string, n is the length of the string, and ^ indicates exponentiation. (The hash value of the empty string is zero.)

從上述String中hashCode()的演算法我們可知，只要String的內容一樣，它們的hashCode()就是一樣的。所以，就有了兩個ProtocolCodecFilter中通過session.getAttribute(DECODER_OUT)會拿到同一物件，也就可能產生相互干擾的情況。

    之於相應的解決方法，可以把相應的Filter類抓出來，如ProtocolCodecFitler：

public class MyProtocolCodecFilter extends IoFilterAdapter {
    /** A logger for this class */
    private static final Logger LOGGER = LoggerFactory.getLogger(MyProtocolCodecFilter.class);

    private static final Class<?>[] EMPTY_PARAMS = new Class[0];

    private static final IoBuffer EMPTY_BUFFER = IoBuffer.wrap(new byte[0]);

    private final AttributeKey ENCODER = new AttributeKey(MyProtocolCodecFilter.class, "encoder");

    private final AttributeKey DECODER = new AttributeKey(MyProtocolCodecFilter.class, "decoder");

    private final AttributeKey DECODER_OUT = new AttributeKey(MyProtocolCodecFilter.class, "decoderOut");

    private final AttributeKey ENCODER_OUT = new AttributeKey(MyProtocolCodecFilter.class, "encoderOut");
	
	...
	...
}

呼叫的時候，由原先的

connector.getFilterChain().addLast("my-codec", new ProtocolCodecFilter(new OwspMessageFactory()));

改成

connector.getFilterChain().addLast("my-codec", new MyProtocolCodecFilter(new OwspMessageFactory()));

注：轉載請註明出處 http://blog.csdn.net/oathevil/article/details/37601391