Cache实战之牛刀小试

标签: cachejobsstringthreadexceptionclass
1333人阅读 评论(0) 收藏 举报
分类:

上个星期,公司一个项目中出现一个性能问题,问题是在并发50个用户的情况下有些API调用会很慢,其实最终的原因是由于后台的C库不是线程安全的,所以我们在Java中用JNI调用的时候使用了同步方法,这些同步方法导致性能在并发情况下急剧下降。

周末回到家,想了一下,如果后台的库不能解决线程安全问题,那就只能在前台解决了。分析了一下开发,发现大部分API调用都是查询方法,所以我想起来可以使用Cache类减缓这种压力。

下面是在使用Cache之前,大体代码结构:

Job.java一个作业类,描述基本作业性息。

 

 

JobService.java一个作用服务接口,描述提供给前台使用的一些方法,这里为了方便只提供了三个方法,两个更新方法,一个查询方法。

 

 

JobServiceImplWithoutCache.java一个没用使用Cache的JobService接口实现类。

 

 

JobServiceImplWithCache.java一个使用ehcache作为缓冲机制的JobService接口实现类。这里只做测试用,所以没有负责最终CacheManager的清理工作,生产环境下应该提供一个CacheManager的封装来管理所有的缓存。

这里需要注意的是Cache对象的创建,其中最后两个参数5和2分别表示

timeToLiveSeconds - the default amount of time to live for an element from its creation date

timeToIdleSeconds - the default amount of time to live for an element from its last accessed or modified date

另外注意在submit和kill方法里,都对cache做了同步更新的操作,从而保证每次getJobs取的数据都是最新的。

 

 

BackendJobManager.java是用来模拟后台JNI代码的,其中三个方法都是同步方法,并且在getJobs()方法里故意sleep(1000)来模拟后台API调用开销。

 

 

Test.java测试类,分不使用Cache和使用Cache两种情况进行测试。其中测试中模拟了50-100个线程来进行并发测试,从结果看效果还是一幕了然的。对于使用Cache的情况,如果并发的更新操作越少,并发查询的效果越好,因此使用Cache在大量查询的应用中还是有比较大的用处的。

 

 

这里只是一个简单的Cache使用的列子,其实如果项目中已经使用了spring的话,spring已经对各种主流的Cache框架做了集成,并且用起来也都是通过配置的方式来做的,这样对调用方来说也更透明,更值得推荐。

 

 

 

 

 

 

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:2646866次
    • 积分:27379
    • 等级:
    • 排名:第208名
    • 原创:470篇
    • 转载:29篇
    • 译文:0篇
    • 评论:440条
    博客专栏
    文章分类
    文章存档
    最新评论