2019独角兽企业重金招聘Python工程师标准>>> 
前些日子在开发中用到了hazelcast，挺不错的一个DD支持分布式map,list等多种容器，而且实现了标准的JDK容器接口，实在是太赞了。和Spring配合使用，应该非常方便，测试的时候set一个标准的JDK容器实现，避免跑测试程序是每次启动hazelcast，影响测试运行速度，运行时注入真正的IMap,IList实例，非常的方便。
非常不幸的是。整个系统框架是基于OSGI的，由于Hazelcast是通过对象的序列化，从本机传输到远端， 在远端反序列化，来实现对象实例在再不同JVM之间的传输的。于是在OSGI严格的classloading机制下，各种ClassNotFound Exception 出现了。
在网上查了一下，发现hazcelcast声称已经解决了这个问题，有些帖子测试没问题，有些帖子测试有问题。。有点混乱。在我们的环境下是对于map,list等容器没问题，对于executorservice,topic等Hazelcast有内部线程控制，有问题。
研究了一下当前的版本1.9.3发现，对于Map，list等容器类的实现，classloader采用的是当前线程的context class loader, 这点是非常巧妙的，因为当前线程一定能Load到目标集合中的类对象，这点也是Hazelcast针对OSGI ClassLoading问题的官方fix,（fix 之前原来使用的是configClassLoader, 简单的说就是hazelcast初始化线程的context class loader）.假设bundle A创建了hazelcast（hazelcast的默认classloader即为A的bundle class loader），bundle B 中取得了一个 hazelcast map对象，向其中放了一个bean（bundle B 的类，没有export） 对象,再取出， 此时如果hazelcast如果使用默认的classloader load bean 对象一定会出 class not found exception, 通过使用current thread 的context class loader（当前线程在B bundle中，当然能load 到自己的类）， hazelcast的fix巧妙的解决了这个问题。
但是对于executorservice,topic等有hazelcast内生线程管理的服务，由于服务的内部线程池都是在Hacelcast初始化的时候预先创建，所以统一使用configClassLoader,于是如果你的hazelcast是在bundle A 中创建好的，然后bundle B 中向executorservice添加了一个Brunnable对象，恭喜你，即使在hazelcast单机模式下，同样会出现ClassNotFound Exception。因为现在hazelcast的内部线程使用的都是默认configClassLoader（Ａ的bundle class loader）。
在这种情况下只能通过dynamic import * 来解决问题。。
结论
1.hazelcast和osgi在一起工作挺难的，如果使用executorservice,topic等组件。
2.如果非要用。。。最好在使用exceutor service 或者 topic的bundle中首次初始化hazelcast,这样可以避免很多潜在的问题。