这次被骗代价十分惨重,特此分享以警后人。
简单说说这次经历。事情发生在2006年7月6日。
我们准备设计log系统。采用p6spy,我们订制了一个自己的log输出类。每次logclass生成一个实例,就把他加进一个Set中。在读 取sql log的时候,我们使用一个静态方法从一个维护logobject的Set中读出一个logobject,使用这个实例来输出。原则上多线程的操作是要同 步的,但是考虑到效率问题,头们决定只是在生成一个logclass实例并向Set中添加时进行同步,而读取时不进行同步。原因就是,我们把 logclass设置成了单态,也就是原则上它只有一个实例。即使多个应用同时启动,也只有固定数量的实例。而这些实例都应该随着web启动而全部预加 载。好,大头拍板了,就这么干。
于是,一个恶根被埋下,并在不知不觉地生长。两年来以半年左右一次的频率,一个Exception不断撩拨着我们的神经。客户那边随着 exception的发生也不断有人来问不过开发人员谁也没有在意,毕竟这个例外很友好,它发生在log输出阶段,发生之后会缺失一段log,不过这不算 什么影响,大家都以为不用去管,看这个还不如去喝喝茶聊聊天。
今年9月,也就是这个月初。客户突然要求对这个不知所谓的东西严密调查,不然就怀疑我们框架的严密性。好家伙,这些平时温和的客户终于爆发了。好吧,调查。
首先跟踪log.发现在发生这个ConcurrentModificationException发生之前有一次类加载。难道类被重新加载了?如 果类被重新加载,基于我对springsingleton的误解,于是我做了一个误判。那就是类被gc掉了。这当然不是没有可能的,如果长时间的闲置,类 被回收那么类的静态量就会被重置,那么如果一个线程访问中间静态量被重置的话,那么就极有可能发生异常。我这样判断还有一个原 因,springsingleton的类实例只有一个,而我用的都是静态方法,也就是没有引用实例,如果gc,那么这个类的实例很可能被收调,没有实例引 用,静态量引用不足以阻止gc。于是接下来我这对我的推断作了一个周的实验,强制gc作了n多遍,无果。我开始对自己的判断产生怀疑,于是仔细察看代码和 log。突然发现几个异常出现都是在web service 开始的一段时间。难道是web service搞得鬼?于是打开web service源代码。一个异常点展现在我面前。每次调用web service,他都会将用到的类重新加载,包括logclass.这样就产生了新的推论。某个线程在访问log class的静态量Set时由于webservice的加载使得set发生变化从而引发异常。试验一下果然如此。
人说千里之堤溃于蚁穴看来不假。如此小的问题竟使得别人对我们的框架产生怀疑,可叹。
总结一下,spring singleton的含义是在一个spring 上下文中保持单态,如果一个jvm上多次加载spring context将使得单态的意义不复存在,与此会产生同步等问题。希望能给大家一些参考。
个人观点:
每次调用web service,他都会将用到的类重新加载,包括log class.
这个是关键。为何每次都会重新加载?
我们看一下Spring的工厂方法。 我们指定了一个application.xml作为配置文件。
如果我们有2个工厂方法呢?他们是2套完全不同的配置,那么所谓的单例还存在吗?
呵呵,不用猜,他们各自使用各自的,不会互相干扰的。
所以。单例一定要在类一级实现,不要指望Spring给你实现。如此,也只能保证一个Context下面的类是单例的。
如果有虚拟主机,虚拟目录,他们的ClassLoader是独立的,同样无法实现单例。
简单说说这次经历。事情发生在2006年7月6日。
我们准备设计log系统。采用p6spy,我们订制了一个自己的log输出类。每次logclass生成一个实例,就把他加进一个Set中。在读 取sql log的时候,我们使用一个静态方法从一个维护logobject的Set中读出一个logobject,使用这个实例来输出。原则上多线程的操作是要同 步的,但是考虑到效率问题,头们决定只是在生成一个logclass实例并向Set中添加时进行同步,而读取时不进行同步。原因就是,我们把 logclass设置成了单态,也就是原则上它只有一个实例。即使多个应用同时启动,也只有固定数量的实例。而这些实例都应该随着web启动而全部预加 载。好,大头拍板了,就这么干。
于是,一个恶根被埋下,并在不知不觉地生长。两年来以半年左右一次的频率,一个Exception不断撩拨着我们的神经。客户那边随着 exception的发生也不断有人来问不过开发人员谁也没有在意,毕竟这个例外很友好,它发生在log输出阶段,发生之后会缺失一段log,不过这不算 什么影响,大家都以为不用去管,看这个还不如去喝喝茶聊聊天。
今年9月,也就是这个月初。客户突然要求对这个不知所谓的东西严密调查,不然就怀疑我们框架的严密性。好家伙,这些平时温和的客户终于爆发了。好吧,调查。
首先跟踪log.发现在发生这个ConcurrentModificationException发生之前有一次类加载。难道类被重新加载了?如 果类被重新加载,基于我对springsingleton的误解,于是我做了一个误判。那就是类被gc掉了。这当然不是没有可能的,如果长时间的闲置,类 被回收那么类的静态量就会被重置,那么如果一个线程访问中间静态量被重置的话,那么就极有可能发生异常。我这样判断还有一个原 因,springsingleton的类实例只有一个,而我用的都是静态方法,也就是没有引用实例,如果gc,那么这个类的实例很可能被收调,没有实例引 用,静态量引用不足以阻止gc。于是接下来我这对我的推断作了一个周的实验,强制gc作了n多遍,无果。我开始对自己的判断产生怀疑,于是仔细察看代码和 log。突然发现几个异常出现都是在web service 开始的一段时间。难道是web service搞得鬼?于是打开web service源代码。一个异常点展现在我面前。每次调用web service,他都会将用到的类重新加载,包括logclass.这样就产生了新的推论。某个线程在访问log class的静态量Set时由于webservice的加载使得set发生变化从而引发异常。试验一下果然如此。
人说千里之堤溃于蚁穴看来不假。如此小的问题竟使得别人对我们的框架产生怀疑,可叹。
总结一下,spring singleton的含义是在一个spring 上下文中保持单态,如果一个jvm上多次加载spring context将使得单态的意义不复存在,与此会产生同步等问题。希望能给大家一些参考。
个人观点:
每次调用web service,他都会将用到的类重新加载,包括log class.
这个是关键。为何每次都会重新加载?
我们看一下Spring的工厂方法。 我们指定了一个application.xml作为配置文件。
如果我们有2个工厂方法呢?他们是2套完全不同的配置,那么所谓的单例还存在吗?
呵呵,不用猜,他们各自使用各自的,不会互相干扰的。
所以。单例一定要在类一级实现,不要指望Spring给你实现。如此,也只能保证一个Context下面的类是单例的。
如果有虚拟主机,虚拟目录,他们的ClassLoader是独立的,同样无法实现单例。