JavaEE:多线程(2):线程状态,线程安全

这篇具有很好参考价值的文章主要介绍了JavaEE:多线程(2):线程状态,线程安全。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

目录

线程状态

线程安全

线程不安全

加锁

互斥性

可重入 

死锁

死锁的解决方法 

Java标准库中线程安全类

内存可见性引起的线程安全问题

等待和通知机制

线程饿死

wait

notify


线程状态

就绪:线程随时可以去CPU上执行,也包含在CPU上执行的线程

阻塞:这个线程暂时不方便去CPU上执行

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

Java中,线程有下面几个状态

1. NEW:Thread对象创建好了,但还没有调用start在系统中创建线程

2. TERMINATED:Thread对象仍然存在,但是系统内部的线程已经执行完毕了

3. RUNNABLE:就绪状态,表示这个线程随时可以去CPU上执行,或者在CPU上执行的线程

4. TIMED_WAITING:指定时间的阻塞,到达一定时间后会自动解除阻塞(sleep或者带有超时时间的join)

5. WAITING:不带时间的阻塞(死等),一定要满足某个条件才能解除阻塞(join或者wait)

6. BLOCKED:由于锁竞争引起的阻塞

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

 JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

⚠只有处于NEW状态才能start

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

如果某个进程卡住了,也可以使用jconsole来查看线程的状态

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee


线程安全

之前提过,引入多线程是为了实现并发编程,但是不能仅仅只靠多线程,因为这里面的问题和注意事项很多

后面一些其他的编程语言引入了封装层次更高的并发编程模型

erlang: actor模型

go: csp模型

js: 基于定时器/异步 模型

python:主要使用基于时间循环模型


线程安全:某个代码无论是在单个线程下执行还是在多个线程下执行都不会产生bug

线程不安全

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

按照常理count = 5w+5w = 10w,但是打印结果远低于10w

而且每次打印的结果不同

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

这里的count++其实是由三个CPU指令构成的

1)load 从内存读取数据到CPU寄存器

2)add 把寄存器中的值 +1

3) save 把寄存器的值写回到内存中

如果两个线程并发执行上面的操作,因为线程之间调度的顺序是不确定的,所以会存在变数

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

除了上面的,还能画出无数种情况。这也是多线程复杂性的缘由,每次写多线程代码都要遍历千万种时间线,确保每种时间线都没有bug

诶为什么有无数种情况嘞?

完全有可能t2执行一次++,而t1执行了2次/3次/更多次++,再排列组合,就会产生很多种情况了

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee


为什么上面那张图第一和第二种执行结果是对的?

t1执行add之后把结果1保存到t1寄存器上,save结果把count = 0改为1;

t1执行add之后把结果2保存到t2寄存器上,save结果把count = 1改为2

(两个线程有各自的上下文(有各自一套寄存器的值),不会相互影响)

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

后面的情况呢?

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

如果程序自增的数目越小,count的差异越难看出来。可能导致第一个线程算完了,第二个线程还没开始运行。


线程不安全的原因总结

1. 操作系统上的线程“抢占式执行”“随机调度”,线程之间的执行顺序不确定(根本原因)

2. 代码结构。代码中多个线程同时修改同一个变量(单线程修改,多线程读取同一个变量没问题;多线程修改不同变量没问题)

(所以之前学过的String对象不可变的特性就是线程安全的)

3. 上面的多线程操作本身不是原子的。(直接原因)

count++需要多个CPU指令,可能一个线程的指令还没执行完就给调度走,给其他线程可乘之机

单个CPU指令就是原子的,要么执行完,要么不执行

(可以通过加锁把这多个CPU指令打包成一个整体,实现线程间的锁竞争)

4. 内存可见性问题

5. 指令重排序问题


加锁

互斥性

加锁具有互斥,排他的特性,一般采用synchronized关键字(调用系统api进行加锁)

加锁前需要准备好一个锁对象,依托于这个锁对象进行加锁和解锁操作

如果一个线程针对一个对象加锁之后,其他线程尝试对这个对象进行加锁操作就会被阻塞(锁冲突/锁竞争),阻塞到前一个线程释放锁为止

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-eeJavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

即使指令会被调度,但是其他线程也无法插手

加锁VS串行

这里给t1和t2加锁,只是让count++这个操作串行执行;而for循环还是并行执行的。这样的运行效率还是会比t1,t2串行执行高的

⚠不存在锁竞争(可能线程不安全)的情况:

1.一个线程加锁,另一个线程不加锁

2.两个线程加的锁对象不同

⚠关于锁的混淆

class Test{
    public int count = 0;
    public void add(){
        synchronized (this){
            count++;
        }
    }
}
public class ThreadDemo20 {
    public static void main(String[] args) throws InterruptedException {
        Test t = new Test();
        Thread t1 = new Thread(()->{
            for (int i = 0; i < 50000; i++) {
                t.add();
            }
        });
        Thread t2 = new Thread(()->{
            for (int i = 0; i < 50000; i++) {
                t.add();
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        System.out.println("count: " + t.count);
    }
}

这段代码执行效果是怎样的?this指的是啥?

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-eethis指向t,而两个线程都调用t.add()方法count++

所以两个线程存在锁竞争

这里的this也可以替换成Test.class,获取Test的类对象,实例化后也就是t

(.class指的是类对象,包含了类的各种信息:类名,属性,访问限定符,参数,接口等)

还可以这么写,之前学过的StringBuilder和StringBuffer就是这么写的,可以保障线程安全

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee在关键方法前加上synchronized

(如果synchronized加到static方法上,就是给类对象加锁)


可重入 

问题:下面的代码可以运行后打印hello吗? 

    public static void main(String[] args) {
        Object locker = new Object();
        Thread t = new Thread(()->{
            synchronized (locker){
                synchronized (locker){
                    System.out.println("hello");
                }
            }
        });
        t.start();
    }

常规认为此时第一个locker对象已经处于加锁状态,这时候如果再尝试对locker加锁不就会阻塞吗?

但是运行完之后发现真能打印hello

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

关键在于这两次加锁其实是同一个线程再运行的

当前由于是同一个线程,此时锁对象就知道了第二次加锁的线程就是持有锁的线程,第二次的操作就可以直接放行通过,不会出现阻塞

Java里面用synchronized加锁,利用了它的可重入特性

真正的加锁,把计数器+1,说明当前这个对象被加锁一次,同时记录线程是谁

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

即使上述synchronized嵌套10层8层的,也不会使解锁操作混乱,始终能够保证在正确的时机解锁,这里的计数器就是用来识别解锁时机的关键要点


死锁

场景:1.一个线程,一把锁,如果锁是不可重入锁,并且一个线程对这把锁加锁两次,就会出现死锁

2. 两个线程,两把锁。线程1获取到锁A,线程2获取到锁B,1尝试获取锁B,2尝试获取锁A,就出现死锁了

    public static void main(String[] args) {
        Object A = new Object();
        Object B = new Object();
        Thread t1 = new Thread(()->{
            synchronized (A){
                //sleep一下,给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时间能拿到A
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                //尝试获取A,但是没有释放B
                synchronized (A){
                    System.out.println("t2拿到两把锁");
                }
            }
        });
        t1.start();
        t2.start();
    }

这段代码就是一个例子,t1和t2谁都不让谁,造成了死锁。结果就是什么都打印不了

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

用jconsole查看线程情况,发现在t1线程第17行代码卡住了

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-eeJavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

t2线程在32行卡住了

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

3. N个线程M把锁

先来说一个经典的哲学家就餐问题

现在有5个滑稽哲学家(每个哲学家就是一个线程),围着餐桌吃一碗面条,放在他们面前有5筷子(5只筷子相当于5把锁),每个哲学家除了吃面还要思考人生

当某个线程拿到锁的时候就会一直持有,除非他吃完了,主动放下筷子(释放锁),其他滑稽不能硬抢筷子

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

由于每个哲学家啥时候吃面,啥时候思考人生这件事不确定,所以绝大部分情况下,这个模型可以正常运行

但是如果所有哲学家都想吃面,都先去拿左手的筷子,一只筷子哪够啊。等他们再去拿右手的筷子时,发现右手的筷子已经被右边的人拿了,此时就产生了死锁


死锁的解决方法 

产生死锁的四个必要条件

1.互斥使用,获取锁的过程是互斥的。一个线程拿到锁,另一个线程只能阻塞等待(最基本特性)

2.不可抢占。一个线程拿到锁之后,只能主动解锁,不能让别的线程强行把锁抢走(最基本特性)

3.请求保持。一个线程拿到锁A之后,持有A的前提下尝试获取B(代码结构)

4.循环等待/环路等待(代码结构,最容易破坏)

解决死锁问题,核心思路就是破坏上述四个必要条件任意一个

几种方案:

1.引入额外的筷子(锁)

2.去掉一个哲学家(线程)

3.引入计数器,限制最多多少人吃面

4.引入加锁顺序规则

5.银行家算法

实际开发中,我们一般采用第4个方案

比如对上面的5个哲学家,针对5只筷子进行编号,约定每个哲学家获取筷子的时候,一定要先获取编号小的筷子,后获取编号大的筷子

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

按照这个逻辑,1号滑稽需要先获取1号筷子,此时其他人获取1号筷子就会阻塞等待

5号筷子就是空闲的


用这个思路,我们可以把上面第2个场景的代码进行修改,约定t2获取锁的顺序,让t2先获取锁A再获取锁B

        Thread t2 = new Thread(()->{
            synchronized (A){
                //sleep一下,给t1时间能拿到A
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
                synchronized (B){
                    System.out.println("t2拿到两把锁");
                }
            }
        });

Java标准库中线程安全类

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

上面的几个类自带锁,在多线程环境下使用,出现问题的概率比较小


内存可见性引起的线程安全问题

如果一个线程写,一个线程读,是否会有线程安全问题?

    private static int flag = 0;

    public static void main(String[] args) {
        Thread t1 = new Thread(()->{
            while(flag == 0){
                //循环体里面先不写东西
            }
            System.out.println("t1进程结束");
        });

        Thread t2 = new Thread(()->{
            System.out.println("输入flag的值:");
            Scanner scanner = new Scanner(System.in);
            flag = scanner.nextInt();
        });
        t1.start();
        t2.start();
    }

这个代码预期只要t2里面输入的不是0就能让t1线程结束

但是最终效果是,我们输入一个非0的值的时候,t1没有真的结束

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

我们来分析一下问题所在

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee这个循环有2条核心指令

1.load读取内存中flag的值到CPU寄存器里

2.拿着寄存器的值和0进行比较(条件跳转)

执行指令的速度是很快的,在用户指令输入前几秒钟,循环已经执行了上百亿次

1.每次load操作执行的结果每次都是一样的

2.load操作开销远远超过条件跳转

load执行很多次,每次结果都一样,而且每次开销巨大,这让JVM产生怀疑,不知道你这里的load操作是否有必要

JVM很激进,直接把load操作优化了(只有前几次进行load操作,后面没发现flag有变化直接干掉load,干掉之后就不再重读读内存,直接使用寄存器之前缓存的值,能大幅度提高循环执行速度)

所以这部分代码,相当于t2修改了内存,但是t1没有看到这个内存的变化,就称为内存可见性问题

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

内存可见性,高度依赖编译器的优化具体实现,啥时候触发啥时候不触发不清楚

我们暴力一点,直接用sleep让t1线程暂停循环,暂停的过程中编译器的优化就不会触发,进程也就能顺利结束了

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

还有一种方法,Java提供了volatile关键字来强制读取内存,使上述的优化被强制关闭,确保每次循环条件都会重新从内存中读取数据

这种方法,牺牲了速度,但是保证了准确性

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

拓展:JMM模型--Java规范文档上的一个概念

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee


等待和通知机制

wait和notify:和join用途类似。因为多个线程之间存在随机调度,所以这里引入wait和notify是为了能从应用层面上干预到多个不同线程代码的执行顺序。

join:等待另一个线程执行完,才继续执行

wait:等待,当另一个线程收到notify通知之后就结束等待,不要求另一个线程必须执行完

换句话说,在应用程序代码中,让后执行的线程,主动放弃被调度的机会,就可以让先执行的线程先把对应的代码执行完了。

这里的干预指的是不影响系统的调度策略,因为内核里调度线程仍然是无序调度。

线程饿死

假设有一台ATM机器,有四个老铁要来取钱。

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

1号牢铁(线程)进去取钱,把ATM一锁,后面排队的人就只能等他取完后才能进去。1号进去后发现ATM里面居然没有钱!那他就只能出来等运钞车给ATM补钱。

1号牢铁释放了锁,其他牢铁就会来竞争这把锁,而且1号牢铁也可以参与到锁竞争中。如果好巧不巧又让1号拿到了锁进去了,发现没钱又出来,再竞争锁。。。。

如此循环,其他牢铁(线程)根本不可能拿到锁进入ATM

(补充:1号线程一直拿得到锁的情况发生概率还是蛮高的。

1号先拿到了锁,处于RUNNABLE状态;而其他线程因为锁冲突出现阻塞,处于BLOCKED状态。

BLOCKED状态的线程需要系统进行唤醒之后才能参与到锁竞争中(唤醒比较慢),1号线程不用被唤醒就可以直接参与竞争)

这种情况叫做“线程饿死”

那怎么解决线程饿死呢?

这里1号牢铁发现自己要执行的逻辑的前提条件不具备(ATM里面没钱),这时1号牢铁就要放弃参与到锁竞争中(进入线程阻塞状态),一直等到条件具备了(ATM里面又有钱了)再去解除阻塞,参与到锁竞争中。

这时候就可以用到wait和notify了,让1号滑稽看看当前条件(ATM是否有钱)是否满足,不满足就wait,其他线程如果让条件满足之后,再通过notify唤醒1号滑稽

对应的代码

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

这里的wait做了三件事:

1.释放锁;

2.进入阻塞等待;

3.当其他线程调用notify的时候,wait解除阻塞,并重写获取到锁


wait

public class ThreadDemo1 {
    public static void main(String[] args) throws InterruptedException {
        Object object = new Object();
        object.wait();
    }
}

1. 随便拿个对象都可以进行wait

2. 直接调用wait会出现监视器异常

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

⚠wait进来要先释放锁,释放锁的前提就是能拿到锁,而sychronized也叫做监视器锁,wait没有放到sychronized里面的话就会出现监视器异常

        Object object = new Object();
        synchronized (object){
            // 调用wait的对象一定要和synchronized中的锁对象是一致的
            object.wait();
        }

wait解的是object的锁,当wait被唤醒后,也能重新获取到object锁

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

代码执行起来在wait这里阻塞了

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

此时就需要notify来把它唤醒

wait有三个版本

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

无参数版本的wait是死等,一直等到notify通知

带有超时时间的wait,当超过预定时间时就停止等待(即使没有notify来通知)


notify

    public static void main(String[] args) {
        Object locker = new Object();
        Thread t1 = new Thread(()->{
            synchronized (locker){
                System.out.println("t1 wait之前");
                try {
                    locker.wait();//wait, sleep和1join都可能被interrupt提前唤醒,需要放到try-catch里面
                } catch (InterruptedException e) {
                    throw new RuntimeException(e);
                }
                System.out.println("t1 wait之后");
            }
        });
        Thread t2 = new Thread(()->{
            try {
                Thread.sleep(1000);
                synchronized (locker){//Java约定notify放到synchronized里面
                    System.out.println("t2 notify之前");
                    locker.notify();
                    System.out.println("t2 notify之后");
                }
            } catch (InterruptedException e) {
                throw new RuntimeException(e);
            }
        });
        t1.start();
        t2.start();
    }

JavaEE:多线程(2):线程状态,线程安全,JavaEE初阶,java,jvm,java-ee

分析代码:

t1线程启动就会调用wait进入阻塞等待,t2线程启动就会先sleep,到时间再进行notify唤醒t1

注意要把sleep写到synchronized外面,否则因为t1和t2执行顺序不确定,可能t2先拿到锁,t1没执行到wait,t2就进行notify了,那逻辑上就有问题了

执行过程:

1.t1执行起来之后,先拿到锁,打印t1 wait之前,进入wait方法

2.t2执行起来之后,先进行sleep,这个sleep可以让t1先拿到锁

3.t2 sleep之后,由于t1在wait状态,锁是释放的。t2就可以拿到锁,接下来打印t2 notify之前,执行notify操作,使t1从1WAITING状态恢复

4.但此时t2还没有释放锁,t1暂时无法获取锁,出现小小的阻塞

5.t2执行完notify之后继续打印t1 wait之后


⚠wait和notify要通过同一个对象来联系

object1.wait();

object2.notify();

此时是无法唤醒的

⚠notifyAll() 唤醒这个对象上所有等待的线程


⚠wait和sleep

wait提供了一个带有超时时间的版本,sleep也能指定时间,时间到解除阻塞继续执行

wait和sleep都可以被提前唤醒:wait由notify唤醒,sleep由interrupt唤醒

使用wait最主要的目标一定是不知道要等多少时间的前提下使用的。而sleep一定要知道要等多少时间才使用文章来源地址https://www.toymoban.com/news/detail-818733.html

到了这里,关于JavaEE:多线程(2):线程状态,线程安全的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【Java EE初阶八】多线程案例(计时器模型)

            计时器类似闹钟,有定时的功能,其主要是到时间就会执行某一操作,即可以指定时间,去执行某一逻辑(某一代码)。         在java标准库中,提供了Timer类,Timer类的核心方法是schedule( 里面包含两个参数,一个是要执行的任务代码,一个是设置多久之后

    2024年01月21日
    浏览(46)
  • 【JavaEE初阶】 线程安全的集合类

    原来的集合类, 大部分都不是线程安全的. Vector, Stack, HashTable, 是线程安全的(不建议用), 其他的集合类不是线程安全的. 为什么不建议使用呢? 因为我们在使用的时候,这些类就会自动的加锁,虽然编译器会自动优化为没有锁竞争的线程进行锁消除的优化,但是呢万一编译器没

    2024年02月08日
    浏览(35)
  • JavaEE:多线程(2):线程状态,线程安全

    目录 线程状态 线程安全 线程不安全 加锁 互斥性 可重入  死锁 死锁的解决方法  Java标准库中线程安全类 内存可见性引起的线程安全问题 等待和通知机制 线程饿死 wait notify 就绪:线程随时可以去CPU上执行,也包含在CPU上执行的线程 阻塞:这个线程暂时不方便去CPU上执行

    2024年01月23日
    浏览(45)
  • javaEE初阶——多线程(九)——JUC常见的类以及线程安全的集合类

    T04BF 👋专栏: 算法|JAVA|MySQL|C语言 🫵 小比特 大梦想 此篇文章与大家分享多线程专题的最后一篇文章:关于JUC常见的类以及线程安全的集合类 如果有不足的或者错误的请您指出! 3.1Callable接口 Callable和Runnable一样,都是用来描述一个任务的 但是区别在于 ,用Callable描述的任务是有

    2024年04月25日
    浏览(43)
  • 【Java EE 初阶】TCP协议的安全效率机制

    目录 1.应用层协议 2.传输层协议 3.UDP协议格式 4.TCP协议格式 5.TCP的安全效率机制 1.确认应答机制 2.超时重传机制 但是,主机A未收到B发来的确认应答,也可能是因为ACK丢失了; 3.连接管理机制 ​编辑 面试题:会不会有可能变成三次挥手? 面试题:第二个FIN丢包了如何处理?

    2024年02月09日
    浏览(44)
  • JavaEE 初阶篇-线程安全的集合类、多线程环境使用 ArrayList、队列、哈希表(HashMap 、ConCurrentHashMap 、HashTable 的区别)

    🔥博客主页: 【 小扳_-CSDN博客】 ❤感谢大家点赞👍收藏⭐评论✍   文章目录         1.0 线程安全的集合类         1.2 线程安全的集合类 - Vector         1.3 线程安全的集合类 - Stack         1.4 线程安全的集合类 - HashTable         2.0 多线程环境使用 ArrayList        

    2024年04月25日
    浏览(51)
  • JavaEE 初阶篇-深入了解多线程安全问题(指令重排序、解决内存可见性与等待通知机制)

    🔥博客主页: 【 小扳_-CSDN博客】 ❤感谢大家点赞👍收藏⭐评论✍ 文章目录         1.0 指令重排序概述         1.1 指令重排序主要分为两种类型         1.2 指令重排序所引发的问题         2.0 内存可见性概述         2.1 导致内存可见性问题主要涉及两个方面      

    2024年04月15日
    浏览(49)
  • 【JavaEE初阶】了解JVM

    JVM启动的时候,会申请到一整个很大的内存区域.JVM是一个应用程序,要从操作系统里申请内存.JVM就根据需要,把空间分为几个部分,每个部分各自有不同的功能.具体划分如下: Native Method Stacks(本地方法栈) :native表示是JVM内部的C++代码.就是给调用native方法(JVM内部的方法)准备的栈空

    2024年02月13日
    浏览(60)
  • 《JavaEE初阶》JVM基础知识

    本章主要介绍JVM中比较重要的三个内容: JVM内存区域划分 JVM类加载机制 JVM垃圾回收机制 当我们创建一个java进程时,启动时会向操作系统申请一块内存,JVM会将这块内存划分为几个区域: 堆 栈 程序计数器 方法区 堆: 堆上主要存放的是new的对象,是最重要的区域,也是内存划分最多

    2024年02月09日
    浏览(38)
  • 了解JVM(JavaEE初阶系列19)

    目录 前言: 1.JVM是如何运行的 2.JVM中的内存区域划分 3.JVM的类加载机制 3.1JVM加载机制的五大步骤 3.1.1加载 3.1.1验证 3.1.1准备 3.1.1解析 3.1.1初始化 3.2总结 3.3JVM启动时机 3.4双亲委派模型 4.JVM中的垃圾回收策略 4.1JVM垃圾回收机制概念 4.2垃圾回收策略 4.2.1判断引用是否有指向 4

    2024年02月10日
    浏览(38)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包