memcache java client_关于使用Memcached-Java-Client往memcache中直接放入对象引发的血案...

[06-05 14:54:42.317]50992 [resin-port-8087-45] ERROR com.schooner.MemCached.AscIIClient - ++++ exception thrown while trying to get object from cache for key: memcacheKey

[06-05 14:54:42.317]50992 [resin-port-8087-45] ERROR com.schooner.MemCached.AscIIClient - packagename.className in EnvironmentClassLoader[web-app:production/webapp/default/api]

[06-05 14:54:42.318]java.io.IOException: packagename.className in EnvironmentClassLoader[web-app:production/webapp/default/api]

[06-05 14:54:42.318]    at com.schooner.MemCached.ObjectTransCoder.decode(Unknown Source)

[06-05 14:54:42.318]    at com.schooner.MemCached.AscIIClient.get(Unknown Source)

[06-05 14:54:42.318]    at com.schooner.MemCached.AscIIClient.get(Unknown Source)

[06-05 14:54:42.318]    at com.schooner.MemCached.AscIIClient.get(Unknown Source)

[06-05 14:54:42.318]    at com.danga.MemCached.MemCachedClient.get(Unknown Source)

大致场景是这样的：两个应用(基础环境一致，memcache的配置也一直)，一个应用(简称应用A)专门提供了一个jsp页面专门来操作memcache中的内容(通过命令行也可以，不过memcache实例数多起来后就会比较痛苦了)，一个是memcache的普通使用者(简称应用B)，应用使用的Memcached-Java-Client都是3.0.0版本的。

在一次升级过程中发现同一个memcacheKey应用A读到的数据和应用B读到的不一致，对比分析了各个配置以及memcacheClient的jar包发现两者核心配置没有任何区别。看了下代码，发现client是先取到memcacheKey.hashcode()，然后通过hashcode对实例列表取余得到对应memcache实例的，第一感觉是hashcode不一致？查看了下String的hashCode方法定义：

public int hashCode()返回此字符串的哈希码。String 对象的哈希码根据以下公式计算：s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]

使用 int 算法，这里 s[i] 是字符串的第 i 个字符，n 是字符串的长度，^ 表示求幂。(空字符串的哈希值为 0。)

单纯看描述没有理由hashcode不一直啊！无论如何，先不纠结这里，先打了点日志，继续看下面的代码，有疑惑的地方都打了日志，此处省略5000字。

日志都加好了，重新mvn install，将包放到服务器上重启服务，运行一看应用A比应用B多了上面黏贴的异常日志。

继续分析源码，client对java的基础类型会直接传给服务端，对自定义的类型多了个序列化的操作。

瞬间石化，大彻大悟！！！

应用A在从服务器端取到数据的时候发现不是java的基础类型，尝试进行反序列化操作。应用A在反序列化的时候会去加载对应的类，但是应用A没有对应的类，所以抛了个大异常，最后返回了个NULL给调用方。

本来平时都是要求自定义对象要转json才往缓存里面放的，但是开发人员素质不一，还是有人没按要求来做，另外应用A中的client也没有定义专门的日志文件，虽然打印了错误日志但是机器数量和日志文件繁多加上表面看没什么问题，因为只是开发者自己查询出来看又问题不影响服务当时就没有回滚升级。