并行是什么,和并发有什么区别
并行:指两个或两个以上事件或活动在同一时刻发生。如多个任务在多个 CPU 或 CPU 的多个核上同时执行,不存在 CPU 资源的竞争、等待行为。
并行与并发的区别
- 并行指多个事件在同一个时刻发生;并发指在某时刻只有一个事件在发生,某个时间段内由于 CPU 交替执行,可以发生多个事件。
- 并行没有对 CPU 资源的抢占;并发执行的线程需要对 CPU 资源进行抢占。
- 并行执行的线程之间不存在切换;并发操作系统会根据任务调度系统给线程分配线程的 CPU 执行时间,线程的执行会进行切换。
并发之原子性、可见性、有序性
并发之原子性、可见性、有序性
https://www.cnblogs.com/guanghe/p/9206635.html
进程、线程、协程
1、进程
进程是具有一定独立功能的程序关于某个数据集合上的一次运行活动,进程是系统进行资源分配和调度的一个独立单位。每个进程都有自己的独立内存空间,不同进程通过进程间通信来通信。由于进程比较重量,占据独立的内存,所以上下文进程间的切换开销(栈、寄存器、虚拟内存、文件句柄等)比较大,但相对比较稳定安全。
2、线程
线程是进程的一个实体,是CPU调度和分派的基本单位,它是比进程更小的能独立运行的基本单位.线程自己基本上不拥有系统资源,只拥有一点在运行中必不可少的资源(如程序计数器,一组寄存器和栈),但是它可与同属一个进程的其他的线程共享进程所拥有的全部资源。线程间通信主要通过共享内存,上下文切换很快,资源开销较少,但相比进程不够稳定容易丢失数据。
3、协程
协程是一种用户态的轻量级线程,协程的调度完全由用户控制。协程拥有自己的寄存器上下文和栈。协程调度切换时,将寄存器上下文和栈保存到其他地方,在切回来的时候,恢复先前保存的寄存器上下文和栈,直接操作栈则基本没有内核切换的开销,可以不加锁的访问全局变量,所以上下文的切换非常快。
进程 VS 线程 进程是资源的分配和调度的独立单元。进程拥有完整的虚拟地址空间,当发生进程切换时,不同的进程拥有不同的虚拟地址空间。而同一进程的多个线程是可以共享同一地址空间
线程是CPU调度的基本单元,进程是系统进行资源分配和调度的单位。
线程比进程小,基本上不拥有系统资源。线程的创建和销毁所需要的时间比进程小很多
一个线程的意外终止会影像整个进程的正常运行,但是一个进程的意外终止不会影像其他的进程的运行。因此,多进程程序安全性更高。
协程可以比作子程序,但执行过程中,子程序内部可中断,然后转而执行别的子程序,在适当的时候再返回来接着执行。协程之间的切换不需要涉及任何系统调用或任何阻塞调用
协程 VS 线程
协程只在一个线程中执行,是子程序之间的切换,发生在用户态上。而且,线程的阻塞状态是由操作系统内核来完成,发生在内核态上,因此协程相比线程节省线程创建和切换的开销
协程中不存在同时写变量冲突,因此,也就不需要用来守卫关键区块的同步性原语,比如互斥锁、信号量等,并且不需要来自操作系统的支持。
进程通信
-
共享存储器系统 相互通信的进程共享某些数据结构或存储区,进程之间通过这些空间进行通信。分两类: (1) 共享数据结构:通信的进程共享某些数据结构,如缓冲区。 公用数据结构的设置及进程间同步的处理由程序员负责,OS只提供共享存储器。 通信方式低效,适于传递少量数据。 (2) 共享存储区:为了传递大量数据,在存储器中划出一块共享存储区。 进程通信前,先向系统申请获得存储区的一个分区,并指定关键字;若系统已经给其他进程分配分区,则把该分区的描述符返回给申请者,申请者将获得的共享存储区连接到本进程上;此后可像读写普通存储器一样读写公用存储区。
-
消息传递系统 程序员直接利用系统提供的一组通信原语进行通信。OS隐藏了通信的细节,简化了通信程序的编制,得到广泛应用。
-
直接通信方式 发送进程利用OS所提供的发送原语直接把消息发给目标进程
-
间接通信方式 发送和接收进程都通过共享实体(邮箱)的方式进行消息的发送和接收
-
管道通信系统 管道是指用于连接一个读进程和一个写进程以实现他们之间通信的一个共享文件,又名pipe文件。 写进程以字符流的形式将大量的数据送入管道(共享文件);而读进程从管道中接收数据。 首创于UNIX系统中,可以传送大量数据。
管道机制必须提供三方面的协调能力: 互斥,即当一个进程正在对pipe执行读/写操作时,其它进程必须等待
同步,当一个进程将一定数量的数据写入,然后就去睡眠等待,直到读进程将数据取走,再去唤醒。读进程与之类似
确定对方是否存在,只有对方存在时,才能通信。
cpu与线程的关系
守护线程是什么?
守护线程(即daemon thread),是个服务线程,准确地来说就是服务其他的线程。
创建线程有哪几种方式?
【Java基础】创建线程有哪几种方式?3种_铁汉柔情li的博客-CSDN博客_创建线程有哪几种方式
①. 继承Thread类创建线程类
- 定义Thread类的子类,并重写该类的run方法,该run方法的方法体就代表了线程要完成的任务。因此把run()方法称为执行体。
- 创建Thread子类的实例,即创建了线程对象。
- 调用线程对象的start()方法来启动该线程。
②. 通过Runnable接口创建线程类
- 定义runnable接口的实现类,并重写该接口的run()方法,该run()方法的方法体同样是该线程的线程执行体。
- 创建 Runnable实现类的实例,并依此实例作为Thread的target来创建Thread对象,该Thread对象才是真正的线程对象。
- 调用线程对象的start()方法来启动该线程。
③. 通过Callable和Future创建线程
- 创建Callable接口的实现类,并实现call()方法,该call()方法将作为线程执行体,并且有返回值。
- 创建Callable实现类的实例,使用FutureTask类来包装Callable对象,该FutureTask对象封装了该Callable对象的call()方法的返回值。
- 使用FutureTask对象作为Thread对象的target创建并启动新线程。
- 调用FutureTask对象的get()方法来获得子线程执行结束后的返回值。
说一下 runnable 和 callable 有什么区别?
- Runnable接口中的run()方法的返回值是void,它做的事情只是纯粹地去执行run()方法中的代码而已;
- Callable接口中的call()方法是有返回值的,是一个泛型,和Future、FutureTask配合可以用来获取异步执行的结果。
线程有哪些状态?
线程通常都有五种状态,创建、就绪、运行、阻塞和死亡。
- 创建状态。在生成线程对象,并没有调用该对象的start方法,这是线程处于创建状态。
- 就绪状态。当调用了线程对象的start方法之后,该线程就进入了就绪状态,但是此时线程调度程序还没有把该线程设置为当前线程,此时处于就绪状态。在线程运行之后,从等待或者睡眠中回来之后,也会处于就绪状态。
- 运行状态。线程调度程序将处于就绪状态的线程设置为当前线程,此时线程就进入了运行状态,开始运行run函数当中的代码。
- 阻塞状态。线程正在运行的时候,被暂停,通常是为了等待某个时间的发生(比如说某项资源就绪)之后再继续运行。sleep,suspend,wait等方法都可以导致线程阻塞。
- 死亡状态。如果一个线程的run方法执行结束或者调用stop方法后,该线程就会死亡。对于已经死亡的线程,无法再使用start方法令其进入就绪
sleep() 和 wait() 有什么区别?
sleep():方法是线程类(Thread)的静态方法,让调用线程进入睡眠状态,让出执行机会给其他线程,等到休眠时间结束后,线程进入就绪状态和其他线程一起竞争cpu的执行时间。因为sleep() 是static静态的方法,他不能改变对象的机锁,当一个synchronized块中调用了sleep() 方法,线程虽然进入休眠,但是对象的机锁没有被释放,其他线程依然无法访问这个对象。
wait():wait()是Object类的方法,当一个线程执行到wait方法时,它就进入到一个和该对象相关的等待池,同时释放对象的机锁,使得其他线程能够访问,可以通过notify,notifyAll方法来唤醒等待的线程
notify()和 notifyAll()有什么区别?
-
如果线程调用了对象的 wait()方法,那么线程便会处于该对象的等待池中,等待池中的线程不会去竞争该对象的锁。
-
当有线程调用了对象的 notifyAll()方法(唤醒所有 wait 线程)或 notify()方法(只随机唤醒一个 wait 线程),被唤醒的的线程便会进入该对象的锁池中,锁池中的线程会去竞争该对象锁。也就是说,调用了notify后只要一个线程会由等待池进入锁池,而notifyAll会将该对象等待池内的所有线程移动到锁池中,等待锁竞争。
-
优先级高的线程竞争到对象锁的概率大,假若某线程没有竞争到该对象锁,它还会留在锁池中,唯有线程再次调用 wait()方法,它才会重新回到等待池中。而竞争到对象锁的线程则继续往下执行,直到执行完了 synchronized 代码块,它会释放掉该对象锁,这时锁池中的线程会继续竞争该对象锁。
线程的 run()和 start()有什么区别?
每个线程都是通过某个特定Thread对象所对应的方法run()来完成其操作的,方法run()称为线程体。通过调用Thread类的start()方法来启动一个线程。
start()方法来启动一个线程,真正实现了多线程运行。这时无需等待run方法体代码执行完毕,可以直接继续执行下面的代码; 这时此线程是处于就绪状态, 并没有运行。 然后通过此Thread类调用方法run()来完成其运行状态, 这里方法run()称为线程体,它包含了要执行的这个线程的内容, Run方法运行结束, 此线程终止。然后CPU再调度其它线程。
run()方法是在本线程里的,只是线程里的一个函数,而不是多线程的。 如果直接调用run(),其实就相当于是调用了一个普通函数而已,直接待用run()方法必须等待run()方法执行完毕才能执行下面的代码,所以执行路径还是只有一条,根本就没有线程的特征,所以在多线程执行时要使用start()方法而不是run()方法。
线程池的好处
降低资源消耗:重复利用线程池中的线程节省线程创建和销毁带来的消耗; 提高性能:当任务需求时,可以不用创建线程直接执行,主要是直接从线程池中取出线程去执行; 提高线程的可管理性:线程是稀缺资源,而且也是任务中不可少的资源,如果频繁的且无限制的创建会消耗系统资源,降低系统稳定性导致系统崩溃,内存溢出等等问题
创建线程池有哪几种方式?
①. newFixedThreadPool(int nThreads)
创建一个固定长度的线程池,每当提交一个任务就创建一个线程,直到达到线程池的最大数量,这时线程规模将不再变化,当线程发生未预期的错误而结束时,线程池会补充一个新的线程。
②. newCachedThreadPool()
创建一个可缓存的线程池,如果线程池的规模超过了处理需求,将自动回收空闲线程,而当需求增加时,则可以自动添加新线程,线程池的规模不存在任何限制。
③. newSingleThreadExecutor()
这是一个单线程的Executor,它创建单个工作线程来执行任务,如果这个线程异常结束,会创建一个新的来替代它;它的特点是能确保依照任务在队列中的顺序来串行执行。
④. newScheduledThreadPool(int corePoolSize)
创建了一个固定长度的线程池,而且以延迟或定时的方式来执行任务,类似于Timer。
java newCachedThreadPool 线程池使用在什么情况下? - 知乎
线程池是如何做到高效并发的。
看整个线程池的工作流程,有以下几个需要特别关注的并发点
①: 线程池状态和工作线程数量的变更。这个由一个AtomicInteger变量 ctl来解决原子性问题。
②: 向工作Worker容器workers中添加新的Worker的时候。这个线程池本身已经加锁了。
③: 工作线程Worker从等待队列中取任务的时候。这个由工作队列本身来保证线程安全,比如LinkedBlockingQueue等。
线程池工作流程
线程池都有哪些状态?
线程池有5种状态:Running、ShutDown、Stop、Tidying、Terminated。
线程池各个状态切换框架图:
线程池中 submit()和 execute()方法有什么区别?
1.submit方便Exception处理
execute 方法执行完成后没有返回值,而submit方法执行后有返回值
2.方法所在的类不同,
execute 方法:java.util.concurrent.Executor;
submit方法:java.util.concurrent.ExecutorService
3.所需要的参数不同,
execute : java.util.concurrent.Executor#execute(java.lang.Runnable)
submit: java.util.concurrent.ExecutorService#submit(java.lang.Runnable, T),
java.util.concurrent.ExecutorService#submit(java.lang.Runnable)
java.util.concurrent.ExecutorService#submit(java.util.concurrent.Callable<T>)
在 java 程序中怎么保证多线程的运行安全?
线程安全在三个方面体现:
- 原子性:提供互斥访问,同一时刻只能有一个线程对数据进行操作,(atomic,synchronized);
- 可见性:一个线程对主内存的修改可以及时地被其他线程看到,(synchronized,volatile);
- 有序性:一个线程观察其他线程中的指令执行顺序,由于指令重排序,该观察结果一般杂乱无序,(happens-before原则)。
多线程锁的升级原理是什么?
锁升级过程就是锁优化
在JDK最开始的时候synchronized属于重量级的锁,每次加锁都是通过操作系统来申请锁,所以会造成synchronized的效率比较低,尤其是随着时代的发展,多线程高并发越来越多,synchronized效率低的缺点就越来越明显,所以jdk对它进行了优化,不再是一开始就向操作系统申请锁,分成偏向锁 - 轻量级锁 - 重量级锁三个过程。
要讲锁升级首先回顾一个知识点,synchronized实际上是对对象加锁的过程(锁一段代码则需指定对象,如果锁方法,普通方法锁的是方法的对象,静态方法则是这个方法所在类的class对象),在对象头的mark word中最低的三位代表锁状态,其中1位是偏向锁位两位是普通锁位,具体如下图:
这次主要关注mark word的后三位的变化,根据变化我们可以得出实际上对象的锁状态可以分成无锁、偏向锁、轻量级锁、重量级锁4个状态
那么接下来就看看锁是如何升级的,首先最开始对象是无锁状态,当一个线程准备对这个对象加锁前验证这三个字节发现了无锁状态,把对象是否偏向设置为1,锁标志位还是01,并把markword的线程ID改为当前线程ID,此时对象处于偏向锁状态。
一个线程继续对该该对象加锁,发现是偏向锁状态,判断偏向锁线程是否是这个线程,如果是则是直接进入,如果偏向线程不是当前线程,也就是存在锁竞争,那么就撤销偏向锁,升级为轻量级锁。
轻量级锁实现方式是各个线程在自己的线程栈生成LockRecord ,用CAS操作将markword设置为指向自己这个线程的LockRecord的指针,设置成功者得到锁,没有成功的将继续使用CAS一直循环直到成功,所以轻量级锁也叫自旋锁,JDK自旋有默认最大值是10次,JDK6对自旋锁进行了优化,自旋的时间不再是固定的,而是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的,比如当前线程在刚刚成功获取过自旋锁,那么虚拟机就会认为这次自旋也很有可能会成功,那么循环次数就可以多进行几次,这就叫自适应自旋。有了自适应自旋就不用我们设置最大循环次数,有JVM监控动态设置。
自旋锁有个缺点就是等待的线程仍然在自旋运行,如果自旋的次数太多或者自旋等待的线程太多会造成CPU消耗过大,这种情况反而不如向操作系统来申请锁,阻塞其他线程。所以在这种情况下锁会升级成重量级锁,没有获取到锁的现在直接在系统级别被挂起,直到系统释放锁唤醒这些挂起的线程,这些线程再次抢锁。
锁的升级过程画了一个简单的图便于理解以上内容,如下图:
CPU运行时优化(高速缓存、指令重排、内存屏障等)
CPU运行时优化(高速缓存、指令重排、内存屏障等)_oahaijgnahz的博客-CSDN博客
Java 中的 volatile 变量是什么
Java 语言提供了一种稍弱的同步机制,即volatile变量。但是volatile并不容器完全被正确、完整的理解。 一般来说,volatile具备2条语义,或者说2个特性。第一是保证volatile修饰的变量对所有线程的可见性,这里的可见性是指当一条线程修改了该变量,新值对于其它线程来说是立即可以得知的。而普通变量做不到这一点。
第二条语义是禁止指令重排序优化,这条语义在JDK1.5才被修复。
关于第一点 :根据JMM,所有的变量存储在主内存,而每个线程还有自己的工作内存,线程的工作内存保存该线程使用到的变量的主内存副本拷贝,线程对变量的操作在工作内存中进行,不能直接读写主内存的变量。在volatile可见性这一点上,普通变量做不到的原因正因如此。比如,线程A修改了一个普通变量的值,然后向主内存进行回写,线程B在线程A回写完成后再从主内存读取,新变量才能对线程B可见。其实,按照虚拟机规范,volatile变量依然有工作内存的拷贝,要借助主内存来实现可见性。但由于volatile的特殊规则保证了新值能立即同步回主内存,以及每次使用从主内存刷新,以此保证了多线程操作volatile变量的可见性。
关于第二点 :先说指令重排序,指令重排序是指CPU采用了允许将多条指令不按规定顺序分开发送给相应的处理单元处理,但并不是说任意重排,CPU需要正确处理指令依赖情况确保最终的正确结果,指令重排序是机器级的优化操作。那么为什么volatile要禁止指令重排序呢,又是如何去做的。举例,DCL(双重检查加锁)的单例模式。volatile修饰后,代码中将会插入许多内存屏障指令保证处理器不发生乱序执行。同时由于Happens-before规则的保证,在刚才的例子中写操作会发生在后续的读操作之前。
除了以上2点,volatile还保证对于64位long和double的读取是原子性的。因为在JMM中允许虚拟机对未被volatile修饰的64位的long和double读写操作分为2次32位的操作来执行,这也就是所谓的long和double的非原子性协定。
基于以上几点,我们知道volatile虽然有这些语义和特性在并发的情况下仍然不能保证线程安全。大部分情况下仍然需要加锁。
除非是以下2种情况:
运算结果不依赖变量的当前值,或者能够确保只有单一线程修改变量的值;
变量不需要与其他的状态变量共同参与不变约束。
什么是CAS操作
如何实现一个自定义锁
基于 CAS 操作实现一个简单的锁_Dongguabai 的博客-CSDN博客
并发编程:如何实现一个简单的锁_Fisher3652的博客-CSDN博客
AQS
深入理解 AQS 底层实现原理_庸人庸的博客-CSDN博客_aqs
面试题:了解Java的AQS吗?_IT技术精选文摘-CSDN博客
从ReentrantLock的实现看AQS的原理及应用 - 美团技术团队
读写锁-ReadWriteLock
读写锁-ReadWriteLock_jawnhaha的博客-CSDN博客
java 降级锁的理解
java 降级锁的理解_zheng199172的博客-CSDN博客_java锁降级
什么是死锁?
死锁是指两个或两个以上的进程在执行过程中,由于竞争资源或者由于彼此通信而造成的一种阻塞的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程。是操作系统层面的一个错误,是进程死锁的简称,最早在 1965 年由 Dijkstra 在研究银行家算法时提出的,它是计算机操作系统乃至整个并发程序设计领域最难处理的问题之一。
怎么防止死锁?
死锁的四个必要条件:
- 互斥条件:进程对所分配到的资源不允许其他进程进行访问,若其他进程访问该资源,只能等待,直至占有该资源的进程使用完成后释放该资源
- 请求和保持条件:进程获得一定的资源之后,又对其他资源发出请求,但是该资源可能被其他进程占有,此事请求阻塞,但又对自己获得的资源保持不放
- 不可剥夺条件:是指进程已获得的资源,在未完成使用之前,不可被剥夺,只能在使用完后自己释放
- 环路等待条件:是指进程发生死锁后,若干进程之间形成一种头尾相接的循环等待资源关系
这四个条件是死锁的必要条件,只要系统发生死锁,这些条件必然成立,而只要上述条件之 一不满足,就不会发生死锁。
理解了死锁的原因,尤其是产生死锁的四个必要条件,就可以最大可能地避免、预防和 解除死锁。
所以,在系统设计、进程调度等方面注意如何不让这四个必要条件成立,如何确 定资源的合理分配算法,避免进程永久占据系统资源。
此外,也要防止进程在处于等待状态的情况下占用资源。因此,对资源的分配要给予合理的规划。
ThreadLocal 是什么?有哪些使用场景?
在每个线程Thread内部有一个ThreadLocal.ThreadLocalMap类型的成员变量threadLocals(ThreadLocalMap是ThreadLocal 的静态内部类 ,由ThreadLocal类来维护和创建),这个threadLocals就是用来存储实际的变量副本的,键值为当前ThreadLocal变量,value为变量副本(即T类型的变量)。 初始时,在Thread里面,threadLocals为空,当通过ThreadLocal变量调用get()方法或者set()方法,就会对Thread类中的threadLocals进行初始化,并且以当前ThreadLocal变量为键值,以ThreadLocal要保存的副本变量为value,存到threadLocals。 然后在当前线程里面,如果要使用副本变量,就可以通过get方法在threadLocals里面查找。
-
实际的通过ThreadLocal创建的副本是存储在每个线程自己的threadLocals中的;
-
为何threadLocals的类型ThreadLocalMap的键值为ThreadLocal对象,因为每个线程中可有多个threadLocal变量,就像sessionLocal和connectionLocal;
-
在进行get之前,必须先set,否则会报空指针异常;如果想在get之前不需要调用set就能正常访问的话,必须重写initialValue()方法。 因为在上面的代码分析过程中,我们发现如果没有先set的话,即在map中查找不到对应的存储,则会通过调用setInitialValue方法返回i,而在setInitialValue方法中,有一个语句是T value = initialValue(), 而默认情况下,initialValue方法返回的是null。
ThreadLocal底层原理实现_奋进的小白粥-CSDN博客_threadlocal底层实现
假设有3个线程(分别为Thread1,Thread2,Thread3),2个ThreadLocal(分别为sessionLocal和connectionLocal),每个线程执行问set之后,每个线程的成员变量threadLocals里就存放着两组k-v,key是sessionLocal和connectionLocal对象,value是各自线程私人的value(他们的key是一样的,value是不一样的)
synchronized 和 volatile 的区别是什么?
- volatile本质是在告诉jvm当前变量在寄存器(工作内存)中的值是不确定的,需要从主存中读取; synchronized则是锁定当前变量,只有当前线程可以访问该变量,其他线程被阻塞住。
- volatile仅能使用在变量级别;synchronized则可以使用在变量、方法、和类级别的。
- volatile仅能实现变量的修改可见性,不能保证原子性;而synchronized则可以保证变量的修改可见性和原子性。
- volatile不会造成线程的阻塞;synchronized可能会造成线程的阻塞。
- volatile标记的变量不会被编译器优化;synchronized标记的变量可以被编译器优化。
synchronized 和 Lock 有什么区别?
- 首先synchronized是java内置关键字,在jvm层面,Lock是个java类;
- synchronized无法判断是否获取锁的状态,Lock可以判断是否获取到锁;
- synchronized会自动释放锁(a 线程执行完同步代码会释放锁 ;b 线程执行过程中发生异常会释放锁),Lock需在finally中手工释放锁(unlock()方法释放锁),否则容易造成线程死锁;
- 用synchronized关键字的两个线程1和线程2,如果当前线程1获得锁,线程2线程等待。如果线程1阻塞,线程2则会一直等待下去,而Lock锁就不一定会等待下去,如果尝试获取不到锁,线程可以不用一直等待就结束了;
- synchronized的锁可重入、不可中断、非公平,而Lock锁可重入、可中断、可公平(公平、非公平两者皆可);
- Lock锁适合大量同步的代码的同步问题,synchronized锁适合代码少量的同步问题。
synchronized 和 ReentrantLock 区别是什么?
synchronized是和if、else、for、while一样的关键字,ReentrantLock是类,这是二者的本质区别。既然ReentrantLock是类,那么它就提供了比synchronized更多更灵活的特性,可以被继承、可以有方法、可以有各种各样的类变量,ReentrantLock是Lock的一种实现,区别可参考上文:
另外,二者的锁机制其实也是不一样的:ReentrantLock底层调用的是Unsafe的park方法加锁,synchronized操作的应该是对象头中mark word。
说一下 atomic 的原理?
Atomic包中的类基本的特性就是在多线程环境下,当有多个线程同时对单个(包括基本类型及引用类型)变量进行操作时,具有排他性,即当多个线程同时对该变量的值进行更新时,仅有一个线程能成功,而未成功的线程可以向自旋锁一样,继续尝试,一直等到执行成功。
Atomic系列的类中的核心方法都会调用unsafe类中的几个本地方法。我们需要先知道一个东西就是Unsafe类,全名为:sun.misc.Unsafe,这个类包含了大量的对C代码的操作,包括很多直接内存分配以及原子操作的调用,而它之所以标记为非安全的,是告诉你这个里面大量的方法调用都会存在安全隐患,需要小心使用,否则会导致严重的后果,例如在通过unsafe分配内存的时候,如果自己指定某些区域可能会导致一些类似C++一样的指针越界到其他进程的问题。