面试-什么是线程安全?

线程安全详解

不是线程的安全

面试官问:“什么是线程安全”,如果你不能很好的回答,那就请往下看吧。

论语中有句话叫“学而优则仕”,相信很多人都觉得是“学习好了可以做官”。然而,这样理解却是错的。切记望文生义。

同理,“线程安全”也不是指线程的安全,而是指内存的安全。为什么如此说呢?这和操作系统有关。

目前主流操作系统都是多任务的,即多个进程同时运行。为了保证安全,每个进程只能访问分配给自己的内存空间,而不能访问别的进程的,这是由操作系统保障的。

在每个进程的内存空间中都会有一块特殊的公共区域,通常称为堆(内存)。进程内的所有线程都可以访问到该区域,这就是造成问题的潜在原因。

假设某个线程把数据处理到一半,觉得很累,就去休息了一会,回来准备接着处理,却发现数据已经被修改了,不是自己离开时的样子了。可能被其它线程修改了。

比如把你住的小区看作一个进程,小区里的道路/绿化等就属于公共区域。你拿1万块钱往地上一扔,就回家睡觉去了。睡醒后你打算去把它捡回来,发现钱已经不见了。可能被别人拿走了。

因为公共区域人来人往,你放的东西在没有看管措施时,一定是不安全的。内存中的情况亦然如此。

所以线程安全指的是,在堆内存中的数据由于可以被任何线程访问到,在没有限制的情况下存在被意外修改的风险。

即堆内存空间在没有保护机制的情况下,对多线程来说是不安全的地方,因为你放进去的数据,可能被别的线程“破坏”。

那我们该怎么办呢?解决问题的过程其实就是一个取舍的过程,不同的解决方案有不同的侧重点。

私有的东西就不该让别人知道

现实中很多人都会把1万块钱藏着掖着,不让无关的人知道,所以根本不可能扔到大马路上。因为这钱是你的私有物品。

在程序中也是这样的,所以操作系统会为每个线程分配属于它自己的内存空间,通常称为栈内存,其它线程无权访问。这也是由操作系统保障的。

如果一些数据只有某个线程会使用,其它线程不能操作也不需要操作,这些数据就可以放入线程的栈内存中。较为常见的就是局部变量。

double avgScore(double[] scores) {
    double sum = 0;
    for (double score : scores) {
        sum += score;
    }
    int count = scores.length;
    double avg = sum / count;
    return avg;
}

这里的变量sum,count,avg都是局部变量,它们都会被分配在线程栈内存中。

假如现在A线程来执行这个方法,这些变量会在A的栈内存分配。与此同时,B线程也来执行这个方法,这些变量也会在B的栈内存中分配。

也就是说这些局部变量会在每个线程的栈内存中都分配一份。由于线程的栈内存只能自己访问,所以栈内存中的变量只属于自己,其它线程根本就不知道。

就像每个人的家只属于自己,其他人不能进来。所以你把1万块钱放到家里,其他人是不会知道的。且一般还会放到某个房间里,而不是仍在客厅的桌子上。

所以把自己的东西放到自己的私人地盘,是安全的,因为其他人无法知道。而且越隐私的地方越好。

大家不要抢,人人有份

相信聪明的你已经发现,上面的解决方案是基于“位置”的。因为你放东西的“位置”只有你自己知道(或能到达),所以东西是安全的,因此这份安全是由“位置”来保障的。

在程序里就对应于方法的局部变量。局部变量之所以是安全的,就是因为定义它的“位置”是在方法里。这样一来安全是达到了,但是它的使用范围也就被限制在这个方法里了,其它方法想用也不用了啦。

现实中往往会有一个变量需要多个方法都能够使用的情况,此时定义这个变量的“位置”就不能在方法里面了,而应该在方法外面。即从(方法的)局部变量变为(类的)成员变量,其实就是“位置”发生了变化。

那么按照主流编程语言的规定,类的成员变量不能再分配在线程的栈内存中,而应该分配在公共的堆内存中。其实也就是变量在内存中的“位置”发生了变化,由一个私有区域来到了公共区域。因此潜在的安全风险也随之而来。

那怎么保证在公共区域的东西安全呢?答案就是,大家不要抢,人人有份。设想你在街头免费发放矿泉水,来了1万人,你却只有1千瓶水,结果可想而知,一拥而上,场面失守。但如果你有10万瓶水,大家一看,水多着呢,不用着急,一个个排着队来,因为肯定会领到。

东西多了,自然就不值钱了,从另一个角度来说,也就安全了。大街上的共享单车,现在都很安全,因为太多了,到处都是,都长得一样,所以连搞破坏的人都放弃了。因此要让一个东西安全,就疯狂的copy它吧。

回到程序里,要让公共区域堆内存中的数据对于每个线程都是安全的,那就每个线程都拷贝它一份,每个线程只处理自己的这一份拷贝而不去影响别的线程的,这不就安全了嘛。相信你已经猜到了,我要表达的就是ThreadLocal类了。

class StudentAssistant {

    ThreadLocal<String> realName = new ThreadLocal<>();
    ThreadLocal<Double> totalScore = new ThreadLocal<>();

    String determineDegree() {
        double score = totalScore.get();
        if (score >= 90) {
            return "A";
        }
        if (score >= 80) {
            return "B";
        }
        if (score >= 70) {
            return "C";
        }
        if (score >= 60) {
            return "D";
        }
        return "E";
    }

    double determineOptionalcourseScore() {
        double score = totalScore.get();
        if (score >= 90) {
            return 10;
        }
        if (score >= 80) {
            return 20;
        }
        if (score >= 70) {
            return 30;
        }
        if (score >= 60) {
            return 40;
        }
        return 60;
    }
}

这个学生助手类有两个成员变量,realName和totalScore,都是ThreadLocal类型的。每个线程在运行时都会拷贝一份存储到自己的本地。

A线程运行的是“张三”和“90”,那么这两个数据“张三”和“90”是存储到A线程对象(Thread类的实例对象)的成员变量里去了。假设此时B线程也在运行,是“李四”和“85”,那么“李四”和“85”这两个数据是存储到了B线程对象(Thread类的实例对象)的成员变量里去了。

线程类(Thread)有一个成员变量,类似于Map类型的,专门用于存储ThreadLocal类型的数据。从逻辑从属关系来讲,这些ThreadLocal数据是属于Thread类的成员变量级别的。从所在“位置”的角度来讲,这些ThreadLocal数据是分配在公共区域的堆内存中的。

说的直白一些,就是把堆内存中的一个数据复制N份,每个线程认领1份,同时规定好,每个线程只能玩自己的那份,不准影响别人的。

需要说明的是这N份数据都还是存储在公共区域堆内存里的,经常听到的“线程本地”,是从逻辑从属关系上来讲的,这些数据和线程一一对应,仿佛成了线程自己“领地”的东西了。其实从数据所在“位置”的角度来讲,它们都位于公共的堆内存中,只不过被线程认领了而已。这一点我要特地强调一下。

其实就像大街上的共享单车。原来只有1辆,大家抢着骑,老出问题。现在从这1辆复制出N辆,每人1辆,各骑各的,问题得解。共享单车就是数据,你就是线程。骑行期间,这辆单车从逻辑上来讲是属于你的,从所在位置上来讲还是在大街上这个公共区域的,因为你发现每个小区大门口都贴着“共享单车,禁止入门”。哈哈哈哈。

共享单车是不是和ThreadLocal很像呀。再重申一遍,ThreadLocal就是,把一个数据复制N份,每个线程认领一份,各玩各的,互不影响。

只能看,不能摸

放在公共区域的东西,只是存在潜在的安全风险,并不是说一定就不安全。有些东西虽然也在公共区域放着,但也是十分安全的。比如你在大街上放一个上百吨的石头雕像,就非常安全,因为大家都弄不动它。

再比如你去旅游时,经常发现一些珍贵的东西,会被用铁栅栏围起来,上面挂一个牌子,写着“只能看,不能摸”。当然可以国际化一点,“only look,don’t touch”。这也是很安全的,因为光看几眼是不可能看坏的。

回到程序里,这种情况就属于,只能读取,不能修改。其实就是常量或只读变量,它们对于多线程是安全的,想改也改不了。

class StudentAssistant {
    final double passScore = 60;
}

比如把及格分数设定为60分,在前面加上一个final,这样所有线程都动不了它了。这就很安全了。

小节一下:以上三种解决方案,其实都是在“耍花招”。

第一种,找个只有自己知道的地方藏起来,当然安全了。

第二种,每人复制1份,各玩各的,互不影响,当然也安全了。

第三种,更狠了,直接规定,只能读取,禁止修改,当然也安全了。

是不是都在“避重就轻”呀。如果这三种方法都解决不了,该怎么办呢?Don’t worry,just continue reading。

没有规则,那就先入为主

前面给出的三种方案,有点“理想化”了。现实中的情况其实是非常混乱嘈杂的,没有规则的。

比如在中午高峰期你去饭店吃饭,进门后发现只剩一个空桌子了,你心想先去点餐吧,回来就坐这里吧。当你点完餐回来后,发现已经被别人捷足先登了。

因为桌子是属于公共区域的物品,任何人都可以坐,那就只能谁先抢到谁坐。虽然你在人群中曾多看了它一眼,但它并不会记住你容颜。

解决方法就不用我说了吧,让一个人在那儿看着座位,其它人去点餐。这样当别人再来的时候,你就可以理直气壮的说,“不好意思,这个座位,我,已经占了”。

我再次相信聪明的你已经猜到了我要说的东西了,没错,就是(互斥)锁。

回到程序里,如果公共区域(堆内存)的数据,要被多个线程操作时,为了确保数据的安全(或一致)性,需要在数据旁边放一把锁,要想操作数据,先获取锁再说吧。

假设一个线程来到数据跟前一看,发现锁是空闲的,没有人持有。于是它就拿到了这把锁,然后开始操作数据,干了一会活,累了,就去休息了。

这时,又来了一个线程,发现锁被别人持有着,按照规定,它不能操作数据,因为它无法得到这把锁。当然,它可以选择等待,或放弃,转而去干别的。

第一个线程之所以敢大胆的去睡觉,就是因为它手里拿着锁呢,其它线程是不可能操作数据的。当它回来后继续把数据操作完,就可以把锁给释放了。锁再次回到空闲状态,其它线程就可以来抢这把锁了。还是谁先抢到锁谁操作数据。

class ClassAssistant {

    double totalScore = 60;
    final Lock lock = new Lock();

    void addScore(double score) {
        lock.obtain();
        totalScore += score;
        lock.release();
    }

    void subScore(double score) {
        lock.obtain();
        totalScore -= score;
        lock.release();
    }
}

假定一个班级的初始分数是60分,这个班级抽出10名学生来同时参加10个不同的答题节目,每个学生答对一次为班级加上5分,答错一次减去5分。因为10个学生一起进行,所以这一定是一个并发情形。

因此加分和减分这两个方法被并发的调用,它们共同操作总分数。为了保证数据的一致性,需要在每次操作前先获取锁,操作完成后再释放锁。

相信世界充满爱,即使被伤害

再回到一开始的例子,假如你往地上仍1万块钱,是不是一定会丢呢?这要看情况了,如果是在人来人往的都市,可以说肯定会丢的。如果你跑到无人区扔地上,可以说肯定不会丢。

可以看到,都是把东西无保护的放到公共区域里,结果却相差很大。这说明安全问题还和公共区域的环境状况有关系。

比如我把数据放到公共区域的堆内存中,但是始终都只会有1个线程,也就是单线程模型,那这数据肯定是安全的。

再者说,2个线程操作同一个数据和200个线程操作同一个数据,这个数据的安全概率是完全不一样的。肯定线程越多数据不安全的概率越大,线程越少数据不安全的概率越小。取个极限情况,那就是只有1个线程,那不安全概率就是0,也就是安全的。

可能你又猜到了我想表达的内容了,没错,就是CAS。可能大家觉得既然锁可以解决问题,那就用锁得了,为啥又冒出了个CAS呢?

那是因为锁的获取和释放是要花费一定代价的,如果在线程数目特别少的时候,可能根本就不会有别的线程来操作数据,此时你还要获取锁和释放锁,可以说是一种浪费。

针对这种“地广人稀”的情况,专门提出了一种方法,叫CAS(Compare And Swap)。就是在并发很小的情况下,数据被意外修改的概率很低,但是又存在这种可能性,此时就用CAS。

假如一个线程操作数据,干了一半活,累了,想要去休息。(貌似今天的线程体质都不太好)。于是它记录下当前数据的状态(就是数据的值),回家睡觉了。

醒来后打算继续接着干活,但是又担心数据可能被修改了,于是就把睡觉前保存的数据状态拿出来和现在的数据状态比较一下,如果一样,说明自己在睡觉期间,数据没有被人动过(当然也有可能是先被改成了其它,然后又改回来了,这就是ABA问题了),那就接着继续干。如果不一样,说明数据已经被修改了,那之前做的那些操作其实都白瞎了,就干脆放弃,从头再重新开始处理一遍。

所以CAS这种方式适用于并发量不高的情况,也就是数据被意外修改的可能性较小的情况。如果并发量很高的话,你的数据一定会被修改,每次都要放弃,然后从头再来,这样反而花费的代价更大了,还不如直接加锁呢。

这里再解释下ABA问题,假如你睡觉前数据是5,醒来后数据还是5,并不能肯定数据没有被修改过。可能数据先被修改成8然后又改回到5,只是你不知道罢了。对于这个问题,其实也很好解决,再加一个版本号字段就行了,并规定只要修改数据,必须使版本号加1。

这样你睡觉前数据是5版本号是0,醒来后数据是5版本号是0,表明数据没有被修改。如果数据是5版本号是2,表明数据被改动了2次,先改为其它,然后又改回到5。

我再次相信聪明的你已经发现了,这里的CAS其实就是乐观锁,上一种方案里的获取锁和释放锁其实就是悲观锁。乐观锁持乐观态度,就是假设我的数据不会被意外修改,如果修改了,就放弃,从头再来。悲观锁持悲观态度,就是假设我的数据一定会被意外修改,那干脆直接加锁得了。

总结

前两种属于隔离法,一个是位置隔离,一个是数据隔离。

然后两种是标记法,一个是只读标记,一个是加锁标记。

最后一种是大胆法,先来怼一把试试,若不行从头再来。

<think>好的,我现在需要回答用户关于“线程安全是什么”的问题。首先,我要确保自己完全理解线程安全的概念。线程安全通常是指在多线程环境下,某个函数、类或对象能够正确地处理多个线程的并发访问,而不会导致数据不一致或其他意外行为。接下来,我应该考虑如何结构清晰地解释这个概念,帮助用户逐步理解。 首先,用户可能对多线程编程有一定的了解,但需要明确线程安全的定义。我需要从基础开始,比如什么是线程,为什么会有线程安全问题。可能需要提到多线程同时访问共享资源时可能出现的问题,比如竞态条件(Race Condition)、数据竞争(Data Race)等。 接下来,应该解释线程安全的具体含义。例如,当一个方法或对象是线程安全的,无论多个线程如何交替执行,它们都能正确协同工作,不会破坏数据的一致性。这里可能需要举例说明,比如一个计数器类,如果多个线程同时增加计数器的值,线程安全的实现会确保最终结果正确。 然后,我需要讨论如何实现线程安全。常见的机制包括使用互斥锁(Mutex)、原子操作(Atomic Operations)、线程局部存储(Thread-Local Storage)等。每个机制都应该简要解释其原理和应用场景,例如互斥锁通过锁定共享资源来防止同时访问,原子操作确保某些操作不可中断等。 此外,应该提到设计线程安全代码时的注意事项,比如避免死锁(Deadlock)、活锁(Livelock)、资源竞争等。可能还需要区分不同的线程安全级别,比如不可变对象(Immutable Objects)天生线程安全,而可变对象需要同步机制。 用户可能需要了解实际应用中的例子,比如在Java中的synchronized关键字,或是C++中的std::mutex。不过,由于问题没有指定具体语言,应该保持语言中立,用通用的概念来解释。 同时,用户可能想知道为什么线程安全重要,特别是在高并发环境下的应用,比如服务器处理多个请求时,如何确保数据的一致性。这部分可以结合实际场景,比如银行转账、库存管理等,说明线程安全问题的后果及解决方案。 需要检查是否存在理解上的误区,比如线程安全不仅仅是加锁,还可能涉及更高级的并发控制机制,如读写锁(ReadWrite Lock)、信号量(Semaphores)、条件变量(Condition Variables)等。同时,可能提到无锁编程(Lock-Free Programming)的概念,虽然复杂但能提高性能。 在组织内容时,应该分步骤或分点,使回答结构清晰。例如,可以分成定义、问题来源、实现机制、注意事项等部分。同时,使用代码示例或比喻来帮助理解,比如用计数器例子说明非线程安全线程安全的区别。 最后,需要确保回答准确,没有技术错误。比如,明确线程安全与并发控制的区别,线程安全是结果,而并发控制是手段。此外,要指出并非所有情况都需要线程安全,只有在共享资源被并发访问时才需要考虑,避免过度同步导致性能下降。 总结思考过程后,我需要将以上内容整理成结构化的回答,确保每个部分逻辑连贯,帮助用户逐步理解线程安全的概念、重要性及实现方法。</think>### 线程安全详解 #### 一、定义 **线程安全**(Thread Safety)指在多线程并发执行时,代码(函数、类、数据结构等)能够**正确、一致地处理共享资源**,避免因线程调度顺序的不确定性导致数据损坏或逻辑错误。简而言之,线程安全的代码在并发环境下无需额外同步机制即可正确运行。 --- #### 二、为什么需要线程安全? 1. **多线程共享资源**: 当多个线程访问同一块内存(如全局变量、静态数据、堆对象)时,可能因操作时序问题(如“写-读”或“写-写”交叉)引发错误。 **示例**: ```python # 非线程安全的计数器 counter = 0 def increment(): global counter temp = counter temp += 1 counter = temp ``` 若两个线程同时执行 `increment()`,可能最终 `counter` 仅增加 1(而非预期的 2)。 2. **竞态条件(Race Condition)**: 程序的正确性依赖于线程操作的执行顺序。例如,未同步的“检查后行动”(Check-Then-Act)操作(如延迟初始化、库存扣减)。 --- #### 三、线程安全的核心问题 1. **数据竞争(Data Race)**: 多个线程同时修改同一数据,且未通过同步机制协调访问顺序。 $$ \text{线程 A 写操作} \quad \text{与} \quad \text{线程 B 读/写操作} \quad \text{重叠} \rightarrow \text{结果不可预测} $$ 2. **原子性破坏**: 本应不可分割的操作(如 `i++`)被中断,导致中间状态暴露。 3. **可见性问题**: 因 CPU 缓存、指令重排序等,某线程的修改可能对其他线程不可见。 --- #### 四、实现线程安全的常见方法 1. **互斥锁(Mutex/Lock)** 通过锁机制确保共享资源在任一时刻仅被一个线程访问。 ```java // Java 示例:使用 synchronized 实现线程安全计数器 public class SafeCounter { private int count = 0; public synchronized void increment() { count++; } } ``` 2. **原子操作(Atomic Operations)** 利用 CPU 指令实现不可中断的原子操作(如 CAS: Compare-And-Swap)。 ```cpp // C++ 示例:原子计数器 #include <atomic> std::atomic<int> counter(0); void increment() { counter.fetch_add(1, std::memory_order_relaxed); } ``` 3. **不可变对象(Immutable Objects)** 对象创建后状态不可修改,天然线程安全(如 Java 的 `String`)。 ```python # Python 示例:元组(不可变)是线程安全的 immutable_data = (1, 2, "safe") ``` 4. **线程局部存储(Thread-Local Storage, TLS)** 每个线程拥有独立的变量副本,避免共享(如 Java 的 `ThreadLocal`)。 5. **设计模式** - 生产者-消费者模型(通过阻塞队列隔离线程) - 读写锁(ReadWrite Lock)分离读/写操作,提升并发性能。 --- #### 五、线程安全的等级 1. **完全线程安全**: 所有操作(包括复合操作)均无需外部同步(如 `ConcurrentHashMap`)。 2. **条件线程安全**: 单个操作是安全的,但组合操作需额外同步(如 `Vector` 的迭代器需外部锁)。 3. **非线程安全**: 需完全由调用方管理同步(如 `ArrayList`)。 --- #### 六、注意事项 1. **死锁(Deadlock)**: 多个线程互相等待对方释放锁,导致永久阻塞。 **避免方法**:按固定顺序获取锁、设置超时、使用无锁结构。 2. **性能开销**: 锁竞争会降低并发效率,需权衡安全性与性能。 3. **过度同步**: 不必要的同步可能限制并发性(如对私有变量的同步)。 --- #### 七、实际应用场景 1. **Web 服务器**:处理并发请求时确保会话数据安全。 2. **金融系统**:账户余额更新需原子性操作。 3. **游戏引擎**:多线程渲染与物理计算的资源协调。 --- ### 总结 线程安全多线程编程的核心挑战,需根据场景选择锁、原子操作、不可变对象等策略。理解数据竞争、原子性、可见性等概念是设计健壮并发程序的基础。在实际开发中,优先使用线程安全库(如 Java 的 `java.util.concurrent`),并借助工具(如竞态检测器)排查潜在问题。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值