详细剖析多线程2----线程安全问题（面试高频考点），月薪20k+的网络安全面试都问些什么

本文链接：https://blog.csdn.net/2301_76328475/article/details/137845452

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上网络安全知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

如果你需要这些资料，可以添加V获取：vip204888 （备注网络安全）

正文

二、线程不安全的原因

首先观察一下下面的这段代码，判断他能否按预期输出10w?

package Thread;
//线程安全问题
public class ThreadDemo16 {
    private static int count=0;
    public static void main(String[] args) throws InterruptedException {
        Thread t1=new Thread(()->{
            for (int i = 0; i < 50000; i++) {
                count++;
            }
        });
        Thread t2=new Thread(()->{
            for (int i = 0; i < 50000; i++) {
                count++;
            }
        });
        t1.start();
        t2.start();
        // 如果没有这俩 join, 肯定不⾏的. 线程还没⾃增完, 就开始打印了
        //很可能打印出来的 count是初始值0，或者计算中间的值，总之是不确定的结果
        t1.join();
        t2.join();
        // 预期结果应该是 10w
        System.out.println("count: " + count);

    }
}

运行之后我们发现打印的结果并不是10w，并且每一次运行的结果都是随机的，由此可见这个线程是不安全的，那么为什么会出现线程不安全这个问题呢？
在这里插入图片描述

由此总结线程不安全的原因-----

【根本原因】==操作系统上的线程是“抢占式执行”的，线程调度是随机的，==这是线程不安全的一个主要原因。随机调度会导致在多线程环境下，程序的执行顺序不确定，程序员必须确保无论哪种执行顺序，代码都能正常运行。
【代码结构】共享资源：多个线程同时访问并修改共享的数据或资源。当多个线程同时访问和修改共享资源时容易引发竞态条件和数据不一致的问题。
①一个线程修改一个变量是安全的
②多个线程修改一个变量是不安全的
③多个线程修改不同变量是安全的
【直接原因】多线程操作不是“原子的”。多线程操作中的原子性指的是一个操作是不可中断的，要么全部执行完成，要么都不执行，不能被其他线程干扰。这对于并发编程非常重要，因为如果一个操作在执行过程中被中断，可能导致数据不一致或者其他意外情况发生。（在上述多线程操作中，count++操作不是“原子的”，而是由多个CPU指令组成的，一个线程执行这些指令时，可能会在执行过程中被抢占，从而给其他线程“可乘之机”。要保证原子性操作，每个CPU指令都应该是“原子的”，即要么完全执行，要么完全不执行。）
内存可见性问题：在多线程环境下调用不可重入的函数（即不支持多线程调用的函数），可能导致数据混乱或程序崩溃。
指令重排序问题：在多线程环境下，由于编译器或处理器对指令进行重排序优化，可能导致预期之外的程序行为。

三、解决线程不安全问题–加锁（synchronized）

针对前述代码我们通过加锁解决线程安全问题

private static int count=0;
    public static void main(String[] args) throws InterruptedException {
        Object locker=new Object();
        Thread t1=new Thread(()->{
            for (int i = 0; i < 50000; i++) {
                synchronized (locker){
                    count++;
                }
            }
        });
        Thread t2=new Thread(()->{
            for (int i = 0; i < 50000; i++) {
                synchronized (locker){
                    count++;
                }
            }
        });
        t1.start();
        t2.start();
        // 如果没有这俩 join, 肯定不⾏的. 线程还没⾃增完, 就开始打印了. 很可能打印出来的 cou
        t1.join();
        t2.join();
        // 预期结果应该是 10w
        System.out.println("count: " + count);
    }

synchronized的特性

1）互斥
synchronized 会起到互斥效果, 某个线程执⾏到某个对象的 synchronized 中时, 其他线程如果也执⾏到同⼀个对象 synchronized 就会阻塞等待.
• 进⼊ synchronized 修饰的代码块, 相当于加锁
• 退出 synchronized 修饰的代码块, 相当于解锁

理解 “阻塞等待”.
针对每⼀把锁, 操作系统内部都维护了⼀个等待队列. 当这个锁被某个线程占有的时候, 其他线程尝试进⾏加锁, 就加不上了, 就会阻塞等待, ⼀直等到之前的线程解锁之后, 由操作系统唤醒⼀个新的线程,再来获取到这个锁.
注意:
• 上⼀个线程解锁之后, 下⼀个线程并不是⽴即就能获取到锁. ⽽是要靠操作系统来 “唤醒”. 这也就是操作系统线程调度的⼀部分⼯作.
• 假设有 A B C 三个线程, 线程 A 先获取到锁, 然后 B 尝试获取锁, 然后 C 再尝试获取锁, 此时 B 和 C
都在阻塞队列中排队等待. 但是当 A 释放锁之后, 虽然 B ⽐ C 先来的, 但是 B 不⼀定就能获取到锁,⽽是和 C 重新竞争, 并不遵守先来后到的规则.
synchronized的底层是使⽤操作系统的mutex lock实现的

2)可重入
我们来看一段代码

package Thread;
//下面这个代码能打印hello吗？
public class ThreadDemo17 {
    public static void main(String[] args) {
        Object lock=new Object();
        Thread t=new Thread(()->{
            synchronized (lock){//真正加锁，同时把计数器+1（初始为0，+1之后就说明当前这个对象被该线程加锁一次）同时记录线程是谁
                synchronized (lock){//先判定当前加锁线程是否持有锁的线程，如果不是同一个线程，阻塞
                                    //如果是同一个线程，就只是++计数器即可，没有其他操作
                    System.out.println("hello");
                }//1 把计数器-1，由于计数器不为0，不会真的解锁
            }//2---应该在2这里解锁，避免1和2之间的逻辑失去锁的保护，执行到这里，再次把计数器-1，此时计数器归零，真正解锁
            //总之就是最外层的{进行加锁，最外层的}进行解锁
        });
        t.start();
    }
}

能够打印hello
在这里插入图片描述
这段代码看起来有锁冲突，但是最终不会出现阻塞，关键在于，这两次加锁，其实是对同一个线程进行的；当前由于是同一个线程，此时锁对象就知道了第二次加锁的线程，就是持有锁的线程，第二次操作，就可以直接放行通过，不会线程阻塞，这个特性，称为“可重入”。可重入锁就是为了防止程序员在写代码时不小心写出来双重锁的效果而使代码出现问题，意思就是就算不小心写了那种双重锁代码，丰富的程序机制也不会让代码有问题。

对于可重入锁来说，内部会持有两个信息
1)当前这个锁是被哪个线程持有的
2)加锁次数的计数器

四、死锁问题

死锁是多线程中一类经典问题
加锁是能解决线程安全问题，但如果加锁方式不当，就可能产生死锁。

死锁的三种典型场景

一个线程一把锁
如果锁是不可重入锁，并且一个线程对这把锁加锁两次，就会出现死锁。（判定一个锁是可重入锁还是不可重入锁的关键在于是否允许同一个线程多次获取同一个锁。可重入锁允许同一个线程多次获取同一个锁，而不可重入锁则不允许。）

两个线程，两把锁线程1获取到锁A，线程2获取到锁B，接下来，1尝试获取B，2尝试获取A，就同样出现死锁了。一旦出现死锁，线程就”卡住“无法继续工作。
eg.

//这是一个死锁代码，严重bug 
public class ThreadDemo18 {
   public static void main(String[] args) {
       Object A = new Object();
       Object B = new Object();
       Thread t1 = new Thread(() -> {
           synchronized (A) {
               // sleep 一下, 是给 t2 时间, 让 t2 也能拿到 B
               try {
                   Thread.sleep(1000);
               } catch (InterruptedException e) {
                   e.printStackTrace();
               }
               // 尝试获取 B, 并没有释放 A
               synchronized (B) {
                   System.out.println("t1 拿到了两把锁!");
               }
           }
       });

       Thread t2 = new Thread(() -> {
           synchronized (B) {
               // sleep 一下, 是给 t1 时间, 让 t1 能拿到 A
               try {
                   Thread.sleep(1000);
               } catch (InterruptedException e) {
                   e.printStackTrace();
               }
               // 尝试获取 A, 并没有释放 B
               synchronized (A) {
                   System.out.println("t2 拿到了两把锁!");
               }
           }
       });
       t1.start();
       t2.start();
   } }

这个死锁问题也可以通过约定加锁顺序解决，先对A加锁，然后对B加锁
在这里插入图片描述