复现一个典型的线上Spring Bean对象的线程安全问题(附三种解决办法)

问题复现

假设线上是一个典型的Spring Boot Web项目,某一块业务的处理逻辑为:

接受一个name字符串参数,然后将该值赋予给一个注入的bean对象,修改bean对象的name属性后再返回,期间我们用了 Thread.sleep(300) 来模拟线上的高耗时业务

代码如下:

@RestController
@RequestMapping("name")
public class NameController {

    @Autowired
    private NameService nameService;

    @RequestMapping("")
    public String changeAndReadName (@RequestParam String name) throws InterruptedException {
        System.out.println("get new request: " + name);
        nameService.setName(name);
        Thread.sleep(300);
        return nameService.getName();
    }

}

上述的nameService也非常简单,一个普通的Spring Service对象

具体代码如下所示:

@Service
public class NameService {

    private String name;

    public NameService() {
    }

    public NameService(String name) {
        this.name = name;
    }

    public String getName() {
        return name;
    }

    public NameService setName(String name) {
        this.name = name;
        return this;
    }
}

相信使用过Spring Boot的伙伴们对这段代码不会有什么疑问,实际运行也没有问题,测试也能跑通,但真的上线后,里面却会产生一个线程安全问题

不相信的话,我们通过线程池,开200个线程来测试NameController就可以复现出来

测试代码如下

    @Test
    public void changeAndReadName() throws Exception {
        ThreadPoolExecutor poolExecutor = new ThreadPoolExecutor(200, 300 , 2000, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(200));
        for (int i = 0; i < 200; i++) {
            poolExecutor.execute(new Runnable() {
                @Override
                public void run() {
                    try {
                        System.out.println(Thread.currentThread().getName() + " begin");
                        Map<String, String> headers = new HashMap<String, String>();
                        Map<String, String> querys = new HashMap<String, String>();

                        querys.put("name", Thread.currentThread().getName());
                        headers.put("Content-Type", "text/plain;charset=UTF-8");
                        HttpResponse response = HttpTool.doGet("http://localhost:8080",
                                "/name",
                                "GET",
                                headers,
                                querys);
                        String res = EntityUtils.toString(response.getEntity());

                        if (!Thread.currentThread().getName().equals(res)) {
                            System.out.println("WE FIND BUG !!!");
                            Assert.assertEquals(true, false);
                        } else {
                            System.out.println(Thread.currentThread().getName() + " get received " + res);
                        }
                    }catch (Exception e) {
                        e.printStackTrace();
                    }
                }
            });
        }
        while(true) {
            Thread.sleep(100);
        }
    }

这段测试代码,启动200个线程,对NameController进行测试,每一个线程将自己的线程名作为参数提交,并对返回结果进行断言,如果返回的值与提交的值不匹配,那么抛出AssertNotEquals异常

实际测试后,我们可以发现200个线程近乎一半以上都会抛出异常

问题产生原因

首先我们来分析一下,当一个线程,向 http://localhost:8080/name 发出请求时,线上的Spring Boot服务,会通过其内置的Tomcat 8.5来接收这个请求

而在Tomcat 8.5中,默认采用的是NIO的实现方式,及每次请求对应一个服务端线程,然后这个服务端的线程,再分配到对应的servlet来处理请求

所以我们可以认为,这并发的200次客户端请求,进入NameController执行请求的,也是分为200个不同的服务端线程来处理

但是Spring提供的Bean对象,并没有默认实现它的线程安全性,即默认状态下,我们的NameController跟NameService都属于单例对象

这下应该很好解释了,200个线程同时操作2个单例对象(一个NameController对象,一个NameService对象),在没有采用任何锁机制的情况下,不产生线程安全问题是不可能的(除非是状态无关性操作)

问题解决办法

按照标题说明的,我这里提供三种解决办法,分别是

  • synchronized修饰方法

  • synchronized代码块

  • 改变bean对象的作用域

接下来对每个解决办法进行说明,包括他们各自的优缺点

synchronized修饰方法

使用synchronized来是修饰可能会产生线程安全问题的方法,应该是我们最容易想到的,同时也是最简单的解决办法,我们仅仅需要在 public String changeAndReadName (@RequestParam String name) 这个方法上,增加一个synchronized进行修饰即可

实际测试,这样确实能解决问题,但是各位是否可以再思考一个问题

我们再来运行测试代码的时候,发现程序运行效率大大降低,因为每一个线程必须等待前一个线程完成changeAndReadName()方法的所有逻辑后才可以运行,而这段逻辑中,就包含了我们用来模拟高耗时业务的 Thread.sleep(300),但它跟我们的线程安全没有什么关系

这种情况下,我们就可以使用第二种方法来解决问题

synchronized代码块

实际的线上逻辑,经常会遇到这样的情况:我们需要确保线程安全的代码,跟高耗时的代码(比如说调用第三方api),很不凑巧的写在同一个方法中

那么这种情况下,使用synchronized代码块,而不是直接修饰方法会来得高效的多

具体解决代码如下:

    @RequestMapping("")
    public String changeAndReadName (@RequestParam String name) throws InterruptedException {
        System.out.println(Thread.currentThread().getName() + " get new request: " + name);
        String result = "";
        synchronized (this) {
            nameService.setName(name);
            result = nameService.getName();
        }
        Thread.sleep(300);
        return result;
    }

再次运行测试代码,我们可以发现效率问题基本解决,但是缺点是需要我们自己把握好哪一块是可能出现线程安全问题的代码(而实际的线上逻辑可能非常复杂,这一块不好把握)

改变bean对象的作用域

现在非常不幸的事情发生了,我们连高耗时代码也是状态相关性的,而同时也需要保证效率问题,那么这种情况下就只能通过牺牲少量的内存来解决问题了

大概思路就是通过改变bean对象的作用域,让每一个服务端线程对应一个新的bean对象来处理逻辑,通过彼此之间互不相关来回避线程安全问题

首先我们需要知道bean对象的作用域有哪些,请见下表

作用域 说明
singleton 默认的作用域,这种情况下的bean都会被定义为一个单例对象,该对象的生命周期是与Spring IOC容器一致的(但出于Spring懒加载机制,只有在第一次被使用时才会创建)
prototype bean被定义为在每次注入时都会创建一个新的对象
request bean被定义为在每个HTTP请求中创建一个单例对象,也就是说在单个请求中都会复用这一个单例对象
session bean被定义为在一个session的生命周期内创建一个单例对象
application bean被定义为在ServletContext的生命周期中复用一个单例对象
              websocket               bean被定义为在websocket的生命周期中复用一个单例对象

清楚bean对象的作用域后,接下来我们就只需要考虑一个问题:修改哪些bean的作用域?

前面我已经解释过,这个案例中,200个服务端线程,在默认情况下是操作2个单例bean对象,分别是NameController和NameService(没错,在Spring Boot下,Controller默认也是单例对象)

那么是不是直接将NameController和NameServie设置为prototype就可以了呢?

如果您的项目是用的Struts2,那么这样做没有任何问题,但是在Spring MVC下会严重影响性能,因为Struts2对请求的拦截是基于类,而Spring MVC则是基于方法

所以我们应该将NameController的作用域设置为request,将NameService设置为prototype来解决

具体操作代码如下

@RestController
@RequestMapping("name")
@Scope("request")
public class NameController {

}
@Service
@Scope("prototype")
public class NameService {

}

参考文献

原创不易,转载请申明出处

案例项目代码: github/liumapp/booklet

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,056评论 5 474
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 84,842评论 2 378
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 148,938评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,296评论 1 272
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,292评论 5 363
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,413评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,824评论 3 393
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,493评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,686评论 1 295
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,502评论 2 318
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,553评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,281评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,820评论 3 305
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,873评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,109评论 1 258
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,699评论 2 348
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,257评论 2 341

推荐阅读更多精彩内容