1.记一次源码追踪分析，从Java到JNI，再到JVM的C++：fileChannel.map()为什么快；源码分析map方法，put方法
2.深入理解和使用volatile关键字
3.1.java的getinstance()如何使用?2.下面的代码是什么意思?
4.synchronized和volatile区别
5.volatile关键字及其作用
6.面试官：说一下 volitile 的内存语义，底层如何实现

记一次源码追踪分析，从Java到JNI，宗圣文化源码再到JVM的C++：fileChannel.map()为什么快；源码分析map方法，put方法

       前言

       在系统IO相关的系统调用有read/write，mmap，sendfile等这些。

       其中read/write是普通的读写，每次都需要将buffer从用户空间拷贝到内核空间；

       而mmap使用的是内存映射，会将磁盘文件对应的页映射（拷贝）到内核空间的page cache，并记录到用户进程的页表中，使得用户空间也可以像操作用户空间一样操作该文件的映射，最后再由操作系统来讲该映射（脏页）回写到磁盘；

       sendfile则使用的是零拷贝技术，在mmap的基础上，当发送数据的时候只拷贝fd和offset等元数据信息，而将数据主体直接拷贝至protocol buffer，实现了内核数据零冗余的零拷贝技术

       本文地址：/post//

问题/目的问题1Java中哪些API使用到了mmap问题2怎么知道该API使用到了mmap，如何追踪程序的系统调用目的1源码中分析验证，从Java到JNI，再到C++：fileChannel.map()使用的是系统调用mmap目的2源码验证分析：调用mmapedByteBuffer.put(Byte[])时JVM在搞些什么？mmap比普通的read/write快在哪？揭晓答案1mmap在Java NIO中的体现/使用

       看一个例子

// 1GBpublic static final int _GB = 1**;File file = new File("filename");FileChannel fileChannel = new RandomAccessFile(file, "rw").getChannel();MappedByteBuffer mmapedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, _GB);for (int i = 0; i < _GB; i++) { count++;mmapedByteBuffer.put((byte)0);}

       其中fileChannel.map()底层使用的就是系统调用mmap，函数签名为： public abstract MappedByteBuffer map(MapMode mode,long position, long size)throws IOException

答案2程序执行的系统调用追踪/** * @author Tptogiar * @description * @date /5/ - : */public class TestMappedByteBuffer{ public static final int _4kb = 4*;public static final int _GB= 1**;public static void main(String[] args) throws IOException, InterruptedException { // 为了方便在日志中找到本段代码的开始位置和结束位置，这里利用文件io来打开始标记FileInputStream startInput = null;try { startInput = new FileInputStream("start1.txt");startInput.read();} catch (IOException e) { e.printStackTrace();}File file = new File("filename");FileChannel fileChannel = new RandomAccessFile(file, "rw").getChannel();MappedByteBuffer map = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, _GB); //我们想分析的语句问题2for (int i = 0; i < _GB; i++) { map.put((byte)0); // 下文中需要分析的语句目的2}// 打结束标记FileInputStream endInput = null;try { endInput = new FileInputStream("end.txt");endInput.read();} catch (IOException e) { e.printStackTrace();}}}

       把上面这段代码编译后把“.class”文件拉到linux执行，并用linux上的strace工具记录其系统调用日志，拿到日志文件我们可以在日志中看到以下信息（关于怎么拿到日志可以参照我的博文：无（代写））：

       注：日志有多行，这里只选取我们关注的

// ...// 看到了我们打的开始标志openat(AT_FDCWD, "start1.txt", O_RDONLY) = -1 ENOENT (No such file or directory)// ... // 打开文件，文件描述符fd为6openat(AT_FDCWD, "filename", O_RDWR|O_CREAT, ) = 6// 判断文件状态fstat(6, { st_mode=S_IFREG|, st_size=, ...}) = 0// ... // 判断文件状态fstat(6, { st_mode=S_IFREG|, st_size=, ...}) = 0// 进行内存映射mmap(NULL, , PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x7f2fd6cd// ...// 程序退出exit(0)// 看到了我们打的结束标志openat(AT_FDCWD, "end.txt", O_RDONLY) = -1 ENOENT (No such file or directory)

       在上面程序的系统调用日志中我们确实看到了我们打的开始标志，结束标志。在开始标志和结束标志之间我们看到了我们的文件"filename"确实被打开了，文件描述符fd = 6；在打开文件后紧接着又执行了系统调用mmap，源码celestia这一点我们Java代码一致，这样，我们就验证了我们答案1中的结论，可以开始我们的下文了

源码追踪分析，从Java到JNI，再到JVM的C++目的1寻源之旅：fileChannel.map()

       我们知道我们执行Java代码fileChannel.map()确实会在底层调用系统调用，那怎么在源码中得到验证呢？怎么落脚于源码进行分析呢？下面开始我们的寻源之旅

       FileChannelImpl.map() 注：由于代码较长，这里代码中略去了一些我们不关注的,比如异常捕获等

public MappedByteBuffer map(MapMode mode, long position, long size)throws IOException{ // ...try { // ...synchronized (positionLock) { // ...long mapPosition = position - pagePosition;mapSize = size + pagePosition;try { // ！我们要找的语句就在这！addr = map0(imode, mapPosition, mapSize);} catch (OutOfMemoryError x) { // 如果内存不足，先尝试进行GCSystem.gc();try { Thread.sleep();} catch (InterruptedException y) { Thread.currentThread().interrupt();}try { // 再次试着mmapaddr = map0(imode, mapPosition, mapSize);} catch (OutOfMemoryError y) { // After a second OOME, failthrow new IOException("Map failed", y);}}} // ...} finally { // ...}}

       上面函数源码中真正执行mmap的语句是在addr = map0(imode, mapPosition, mapSize),于是我们寻着这里继续追踪

       FileChannelImpl.map0()

// Creates a new mappingprivate native long map0(int prot, long position, long length)throws IOException;

       可以看到，该方法是一个native方法，所以后面的源码我们需要到这个FileChannelImpl.class对应的fileChannelImpl.c中去看，所以我们需要去找到JDK的源码

       在JDK源码中我们找到fileChannelImpl.c文件

       fileChannelImpl.c 根据JNI的对应规则，我们找到该文件内对应的Java_sun_nio_ch_FileChannelImpl_map0方法，其源码如下：

JNIEXPORT jlong JNICALLJava_sun_nio_ch_FileChannelImpl_map0(JNIEnv *env, jobject this, jint prot, jlong off, jlong len){ void *mapAddress = 0;jobject fdo = (*env)->GetObjectField(env, this, chan_fd);jint fd = fdval(env, fdo);int protections = 0;int flags = 0;if (prot == sun_nio_ch_FileChannelImpl_MAP_RO) { protections = PROT_READ;flags = MAP_SHARED;} else if (prot == sun_nio_ch_FileChannelImpl_MAP_RW) { protections = PROT_WRITE | PROT_READ;flags = MAP_SHARED;} else if (prot == sun_nio_ch_FileChannelImpl_MAP_PV) { protections =PROT_WRITE | PROT_READ;flags = MAP_PRIVATE;}// ！我们要找的语句就在这里！mapAddress = mmap(0,/* Let OS decide location */len,/* Number of bytes to map */protections,/* File permissions */flags,/* Changes are shared */fd, /* File descriptor of mapped file */off); /* Offset into file */if (mapAddress == MAP_FAILED) { if (errno == ENOMEM) { JNU_ThrowOutOfMemoryError(env, "Map failed");return IOS_THROWN;}return handle(env, -1, "Map failed");}return ((jlong) (unsigned long) mapAddress);}

       我们要找的语句就上面代码中的mapAddress = mmap(0,len,protections,flags,fd,off),至于为什么不是直接的mmap，而是mmap，是因为这里的mmap是一个宏，在文件上方有其定义，如下：

#define mmap mmap

       至此，我们就在源码中得到验证了我们问题2中的结论：fileChannelImpl.map()底层使用的是mmap系统调用

目的2寻源之旅：mmapedByteBuffer.put(Byte[ ])

       接着我们来看看当我们调用mmapedByteBuffer.put(Byte[])JVM底层在搞些什么动作

       MappedByteBuffer ?首先我们得知道，当我们执行MappedByteBuffer map = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, _GB)时，实际返回的对象是DirectByteBuffer类的实例，因为MappedByteBuffer为抽象类，且只有DirectByteBuffer继承了它，看下面两图就明白了

       DirectByteBuffer 于是我们找到DirectByteBuffer内的put(Byte[ ])方法

public ByteBuffer put(byte x) { unsafe.putByte(ix(nextPutIndex()), ((x)));return this;}

       可以看到该方法内实际是调用Unsafe类内的putByte方法来实现功能的，所以我们还得去看Unsafe类

       Unsafe.class

public native voidputByte(long address, byte x);

       该方法在Unsafe内是一个native方法，所以所以我们还得去看unsafe.cpp文件内对应的实现

       unsafe.cpp

       在JDK源码中，我们找到unsafe.cpp

       在这份源码内，razor 源码没有使用JNI内普通加前缀的方法来形成对应关系

       不过我们还是能顺着源码的蛛丝轨迹找到我们要找的方法

       注意到源码中有这样的注册机制，所以我们可以知道我们要找的代码就是上图中标注的代码

       顺藤摸瓜，我们就找到了该方法的定义

UNSAFE_ENTRY(void, Unsafe_SetNative##Type(JNIEnv *env, jobject unsafe, jlong addr, java_type x)) \UnsafeWrapper("Unsafe_SetNative"#Type); \JavaThread* t = JavaThread::current(); \t->set_doing_unsafe_access(true); \void* p = addr_from_java(addr); \*(volatile native_type*)p = x; \t->set_doing_unsafe_access(false); \UNSAFE_END \

       该方法内主要的逻辑语句就是以下两句：

/** * @author Tptogiar * @description * @date /5/ - : */public class TestMappedByteBuffer{ public static final int _4kb = 4*;public static final int _GB= 1**;public static void main(String[] args) throws IOException, InterruptedException { // 为了方便在日志中找到本段代码的开始位置和结束位置，这里利用文件io来打开始标记FileInputStream startInput = null;try { startInput = new FileInputStream("start1.txt");startInput.read();} catch (IOException e) { e.printStackTrace();}File file = new File("filename");FileChannel fileChannel = new RandomAccessFile(file, "rw").getChannel();MappedByteBuffer map = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, _GB); //我们想分析的语句问题2for (int i = 0; i < _GB; i++) { map.put((byte)0); // 下文中需要分析的语句目的2}// 打结束标记FileInputStream endInput = null;try { endInput = new FileInputStream("end.txt");endInput.read();} catch (IOException e) { e.printStackTrace();}}}0

       至此，我们就知道：其实我们调用mmapedByteBuffer.put(Byte[ ])时，JVM底层并不需要涉及到系统调用（这里也可以用strace工具追踪从而得到验证）。也就是说通过mmap映射的空间在内核空间和用户空间是共享的，我们在用户空间只需要像平时使用用户空间那样就行了————获取地址，设置值，而不涉及用户态，内核态的切换

总结

       fileChannelImpl.map()底层用调用系统函数mmap

       fileChannelImpl.map()返回的其实不是MappedByteBuffer类对象，而是DirectByteBuffer类对象

       在linux上可以通过strace来追踪系统调用

       JNI中“.class”文件内方法与“.cpp”文件内函数的对应关系不止是前缀对应的方法，还可以是注册的方式，这一点的追寻代码的时候有很大帮助

       directByteBuffer.put()方法底层并没有涉及系统调用，也就不需要涉及切态的性能开销(其底层知识执行获取地址，设置值的操作)，所以mmap的性能就比普通读写read/write好

       ...

原文：/post/

深入理解和使用volatile关键字

       大家好！今天小黑要和大家聊聊Java并发编程的一个重要话题——volatile关键字。在Java的世界里，掌握并发编程是一项必备技能，尤其是当咱们处理多线程应用时。你可能听说过这样的情况：即使你的代码看起来毫无问题，但在并发环境下，它们就像是刚从床上起来的头发，乱七八糟！为什么会这样呢？原因在于多线程操作时存在的一些难以察觉的陷阱，比如变量的可见性问题、操作的原子性问题等等。

       Java提供了多种机制来处理这些问题，其中volatile关键字就是一个重要的工具。可能有人会问，夏雨源码这个volatile到底是个什么东西？简单来说，它是Java提供的一种轻量级的同步机制。但别小看了这个“轻量级”，它在确保变量在多线程环境下的可见性方面，可是有着不可小觑的作用。在接下来的内容中，小黑将带你深入了解volatile，以及它在Java并发编程中的应用和局限性。

       好了，现在咱们来深入了解一下volatile这个“神秘”的关键字。在Java中，volatile是一种用于声明变量的修饰符。它告诉JVM和编译器，这个变量可能会被多个线程同时访问，而且还不通过锁来控制。这听起来有点像是给变量加了一个“注意”标签，让它在并发环境下表现得更好。

       首先，小黑给大家强调一下，volatile主要解决的是可见性问题。可见性，就像它字面上的意思，确保当一个线程修改了volatile变量的值时，其他线程能够立即知道这个改变。这听起来很简单，但在并发编程中，这个特性非常重要。为什么呢？因为在多线程环境中，每个线程可能在自己的工作内存中保留了变量的副本，这就导致了一个线程对变量的修改，其他线程不一定能立即看到。kcm 源码

       下面小黑用一个小例子来展示volatile的使用。假设有一个简单的场景，我们有一个标志位变量，控制着一个线程的运行状态：

       在这个例子中，flag变量被声明为volatile。这意味着，当stopThread方法被调用，将flag设置为true时，正在运行的线程会立即看到这个改变，并退出while循环。

       volatile是Java并发编程中一个非常有用的工具，尤其是在处理可见性问题时。但是它并不是万能的，有它的局限性。

       最后，通过这些例子，咱们可以看到volatile在实际编程中的应用场景。它是一个强大的工具，但要记住它的局限性和合适的使用场景。咱们在编写并发程序时，应该根据具体需求选择合适的同步机制。

1.java的getinstance()如何使用?2.下面的代码是什么意思?

       单例模式解释。

       传统的单例模式实现方式存在启动速度慢的问题，因为它在类加载时即创建静态实例。为了解决这一问题，可以使用懒加载方式。

       接下来，确保实例在第一次调用getInstance方法时创建。在多线程环境下，使用synchronized修饰getInstance方法以确保线程安全。

       尝试优化，发现使用volatile关键字可以避免多线程下创建多个实例的问题。volatile关键字用于标记变量，表示其值由不同线程修改，且该变量不会被线程局部缓存，直接操作内存。

       理解volatile关键字的定义：它用于表示一个变量可能由不同线程修改，且确保所有读写操作直接作用于内存，而非线程缓存。其中，第二点尤为重要，它确保了变量在多线程环境下的原子性。

       然而，虽然使用volatile关键字可以避免创建多个实例的问题，但需要注意JVM的实现可能不遵循volatile的规则。为确保安全，可以使用内部类的方式实现单例模式。

       此外，Java 5及之后版本提供了更简洁的单例实现方式，使用枚举（enum）。

       总结，正确的Java单例模式实现需要考虑启动效率、多线程安全、JVM实现等因素。通过优化和选择合适的方法，可以高效且安全地实现单例模式。

synchronized和volatile区别

       synchronized和volatile区别：

       volatile本质：是java虚拟机(JVM)当前变量在工作内存中的值是不确定的，需要从主内存中读取；synchronized则是锁定当前的变量，只有当前线程可以访问到该变量，其他的线程将会被阻塞。

       扩展资料

       volatile只能实现变量的修改可见性，并不能保证原子性；而synchronized则可以保证变量的修改可见性和原子性。

       volatile只能使用在变量级别；synchronized则可以使用在变量、方法、和类级别的。

       volatile不会造成线程的阻塞；synchronized可能会造成线程的阻塞。

volatile关键字及其作用

       本文主要介绍Java语言中的volatile关键字，内容涵盖volatile的保证内存可见性、禁止指令重排等。

       1 保证内存可见性

       1.1 基本概念

       可见性是指线程之间的可见性，一个线程修改的状态对另一个线程是可见的。也就是一个线程修改的结果，另一个线程马上就能看到。

       1.2 实现原理

       当对非volatile变量进行读写的时候，每个线程先从主内存拷贝变量到CPU缓存中，如果计算机有多个CPU，每个线程可能在不同的CPU上被处理，这意味着每个线程可以拷贝到不同的CPU cache中。

       volatile变量不会被缓存在寄存器或者对其他处理器不可见的地方，保证了每次读写变量都从主内存中读，跳过CPU cache这一步。当一个线程修改了这个变量的值，新值对于其他线程是立即得知的。

       2 禁止指令重排

       2.1 基本概念

       指令重排序是JVM为了优化指令、提高程序运行效率，在不影响单线程程序执行结果的前提下，尽可能地提高并行度。指令重排序包括编译器重排序和运行时重排序。

       在JDK1.5之后，可以使用volatile变量禁止指令重排序。针对volatile修饰的变量，在读写操作指令前后会插入内存屏障，指令重排序时不能把后面的指令重排序到内存屏障后面。

       2.2 指令重排带来的问题

       如果一个操作不是原子的，就会给JVM留下重排的机会。

       如果线程A中的指令发生了重排序，那么B中很可能就会拿到一个尚未初始化或尚未初始化完成的context,从而引发程序错误。

       2.3 禁止指令重排的原理

       volatile关键字提供内存屏障的方式来防止指令被重排，编译器在生成字节码文件时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。

       JVM内存屏障插入策略：

       每个volatile写操作的前面插入一个StoreStore屏障；

       在每个volatile写操作的后面插入一个StoreLoad屏障；

       在每个volatile读操作的后面插入一个LoadLoad屏障；

       在每个volatile读操作的后面插入一个LoadStore屏障。

       2.4 指令重排在双重锁定单例模式中的影响

       基于双重检验的单例模式(懒汉型)

       instance= new Singleton()并不是一个原子操作，其实际上可以抽象为下面几条JVM指令：

       上面操作2依赖于操作1，但是操作3并不依赖于操作2。所以JVM是可以针对它们进行指令的优化重排序的，经过重排序后如下：

       指令重排之后，instance指向分配好的内存放在了前面，而这段内存的初始化被排在了后面。在线程A执行这段赋值语句，在初始化分配对象之前就已经将其赋值给instance引用，恰好另一个线程进入方法判断instance引用不为null，然后就将其返回使用，导致出错。

       解决办法

       用volatile关键字修饰instance变量，使得instance在读、写操作前后都会插入内存屏障，避免重排序。

       3 适用场景

       (1) volatile是轻量级同步机制。在访问volatile变量时不会执行加锁操作，因此也就不会使执行线程阻塞，是一种比synchronized关键字更轻量级的同步机制。

       (2) volatile**无法同时保证内存可见性和原子性。加锁机制既可以确保可见性又可以确保原子性，而volatile变量只能确保可见性**。

       (3) volatile不能修饰写入操作依赖当前值的变量。声明为volatile的简单变量如果当前值与该变量以前的值相关，那么volatile关键字不起作用，也就是说如下的表达式都不是原子操作：“count++”、“count = count+1”。

       (4) 当要访问的变量已在synchronized代码块中，或者为常量时，没必要使用volatile；

       (5) volatile屏蔽掉了JVM中必要的代码优化，所以在效率上比较低，因此一定在必要时才使用此关键字。

       想获取更多知识和学习资料可以扫描下方二维码或是点击链接

       mp.weixin.qq.com/s/vkvY...

面试官：说一下 volitile 的内存语义，底层如何实现

       volatile作为Java中的一个关键字，主要用于解决多线程环境下的并发问题。它具有两个关键特性：可见性和有序性。volatile使得对它的读写操作可以确保在不同线程间的可见性，即一个线程对volatile变量的修改，其他线程可以立即看到。同时，它还确保了读写操作的原子性，即不能被其他操作打断。

       volatile的写-读与锁的释放-获取在内存层面有相同的效应。当执行写入volatile操作时，会将更改同步至主内存，使得所有线程都能读取到最新的值。相反，当读取一个volatile变量时，JVM会从主内存读取该变量的值，以确保读取到的是最新值，而不会读取到可能由其他线程在当前读取之前未同步到主内存的旧值。

       实现volatile内存语义的关键在于内存屏障的插入。JMM通过在volatile写操作前插入StoreStore屏障，确保在写操作前，所有的普通写操作对所有处理器都是可见的。同样，volatile读操作后插入的StoreLoad屏障则确保读操作后，所有读操作都从主内存获取数据，而不是从本地缓存。

       在多核环境中，volatile与CAS（Compare And Swap）底层实现都基于CPU的lock指令，但它们的使用场景和效果有所不同。lock指令用于原子操作，限制处理器重排序，确保指令执行的顺序性。而volatile和CAS则通过内存屏障控制指令执行的顺序，确保不同线程之间的可见性和一致性。

       在实现锁的机制时，lock前缀使用了环形总线（Ringbus）和MESI（Modified, Exclusive, Shared, Invalid）缓存一致性协议来管理缓存状态。MESI协议通过缓存状态的变化确保数据的一致性，同时，引入了Store buffer和Invalidate queue来优化性能，提升多核环境下的读写效率。读写屏障的引入进一步加强了不同核心间缓存的一致性，确保在不同核心上的缓存可以得到强同步。

       总结而言，volatile内存语义的实现通过内存屏障和特定的缓存一致性协议，确保了多线程环境下的数据可见性和一致性，从而有效避免了数据竞争和死锁问题。理解volatile和锁机制的底层实现对于开发高性能、并发安全的多线程应用至关重要。