故事介绍
故事开始于一个快速需求 - 【*&%^%$&*(&%%】,本次需求要求给涉及到的xxx - 模块相关search接口加一个search结果适配.
对于search出来的结果:
1、有协议价的 - 验证是否指定了property的范围,如果指定了范围且不在范围内的,则过滤掉协议价这个标识.
2、无协议价的: nothing...
作为当前需求owner以及原功能参与者,听到这个需求不要太简单.那小脾气一下就上来了，对着电脑啪啦啪啦就是一顿敲.事毕...长长糊了一口气...
本以为故事情节会照着剧本走,毕竟咱程序猿写代码时没有bug的!!
是的,故事情节一直按照着稳定切平缓的节奏发展,直到需求开发完之后看到了之前写的一段代码,如下:
构建search条件的方法:
构建匹配条件的方法类:
这个时候不知道哪根筋不对,估计是中午吃了最近疯狂涨价的猪肉的原因.越看这块儿越不爽,略微带了点儿强迫症.就想操刀调整一下写法.想做就做
于是调整后出现了以下代码:
构建search条件的方法:
构建profile匹配条件的方法类:
调整过后呢自我感觉比之前的满意了那么一点儿,然后自己发布代码,在开发环境简单点了点.达到了预期的search结果,一切都是那么完美......直到qa同学发现search xxxx的时候没有达到预期结果????
说实话,这一瞬间心情是相当的复杂....大型翻车现场????莫非是qa同学验证姿势不对？一定是的...小生一定要找到方法说服他.毕竟咱嘴上得残留程序猿最后的骄傲不是??
好了好了,迫于背后的明锐目光,赶紧找找咋肥事.....这俗话说的话,不找不知道,一找吓一跳啊..我滴个乖乖~~富有征服力的眼神一行一行扫描可能出现问题的代码逻辑,业务逻辑没啥问题啊啊啊.？？最后发现问题出在了它:
@Component注解以及他的使用上,@Component注解的对象都是单例模式,在通过@Resource引用的时候,内部的变量
是非线程安全的.这样的处理方式就导致了页面search的时候可能出现由于线程安全问题导致的搜索结果不一致问题.
!@##@@%$%之后,吓得我赶紧就此问题做了代码紧急修复,去掉@Resource的方式引用,增加静态方法初始化每次调用的参数,至此问题解决.代码如下:
构建search条件的方法:
构建profile匹配条件的方法类:
总结：
忽略了@component的使用注意事项,更忽略了可能存在的线程安全问题.
一时修改一时爽,一直修改一直爽.
除了上诉解决办法外,也可以通过new的方式或者使用@Resouce方法,不过这样的情况下就需要在每次调用的时候初始化上诉的内部变量.
至此,阿门......
