作者归档:flydean

小师妹学JVM之:深入理解JIT和编译优化-你看不懂系列

精美图文讲解Java AQS 共享式获取同步状态以及Semaphore的应用

目录

简介

小师妹已经学完JVM的简单部分了,接下来要进入的是JVM中比较晦涩难懂的概念,这些概念是那么的枯燥乏味,甚至还有点惹人讨厌,但是要想深入理解JVM,这些概念是必须的,我将会尽量尝试用简单的例子来解释它们,但一定会有人看不懂,没关系,这个系列本不是给所有人看的。

更多精彩内容且看:

JIT编译器

小师妹:F师兄,我的基础已经打牢了吗?可以进入这么复杂的内容环节了吗?

小师妹不试试怎么知道不行呢?了解点深入内容可以帮助你更好的理解之前的知识。现在我们开始吧。

上次我们在讲java程序的处理流程的时候,还记得那通用的几步吧。

小师妹:当然记得了,编写源代码,javac编译成字节码,加载到JVM中执行。

对,其实在JVM的执行引擎中,有三个部分:解释器,JIT编译器和垃圾回收器。

解释器会将前面编译生成的字节码翻译成机器语言,因为每次都要翻译,相当于比直接编译成机器码要多了一步,所以java执行起来会比较慢。

为了解决这个问题,JVM引入了JIT(Just-in-Time)编译器,将热点代码编译成为机器码。

Tiered Compilation分层编译

小师妹你知道吗?在JDK8之前,HotSpot VM又分为三种。分别是 client VM, server VM, 和 minimal VM,分别用在客户端,服务器,和嵌入式系统。

但是随着硬件技术的发展,这些硬件上面的限制都不是什么大事了。所以从JDK8之后,已经不再区分这些VM了,现在统一使用VM的实现来替代他们。

小师妹,你觉得Client VM和Server VM的本质区别在哪一部分呢?

小师妹,编译成字节码应该都是使用javac,都是同样的命令,字节码上面肯定是一样的。难点是在执行引擎上面的不同?

说的对,因为Client VM和Server VM的出现,所以在JIT中出现了两种不同的编译器,C1 for Client VM, C2 for Server VM。

因为javac的编译只能做少量的优化,其实大量的动态优化是在JIT中做的。C2相对于C1,其优化的程度更深,更加激进。

为了更好的提升编译效率,JVM在JDK7中引入了分层编译Tiered compilation的概念。

对于JIT本身来说,动态编译是需要占用用户内存空间的,有可能会造成较高的延迟。

对于Server服务器来说,因为代码要服务很多个client,所以磨刀不误砍柴工,短暂的延迟带来永久的收益,听起来是可以接受的。

Server端的JIT编译也不是立马进行的,它可能需要收集到足够多的信息之后,才进行编译。

而对于Client来说,延迟带来的性能影响就需要进行考虑了。和Server相比,它只进行了简单的机器码的编译。

为了满足不同层次的编译需求,于是引入了分层编译的概念。

大概来说分层编译可以分为三层:

  1. 第一层就是禁用C1和C2编译器,这个时候没有JIT进行。
  2. 第二层就是只开启C1编译器,因为C1编译器只会进行一些简单的JIT优化,所以这个可以应对常规情况。
  3. 第三层就是同时开启C1和C2编译器。

在JDK7中,你可以使用下面的命令来开启分层编译:

-XX:+TieredCompilation

而在JDK8之后,恭喜你,分层编译已经是默认的选项了,不用再手动开启。

OSR(On-Stack Replacement)

小师妹:F师兄,你刚刚讲到Server的JIT不是立马就进行编译的,它会等待一定的时间来搜集所需的信息,那么代码不是要从字节码转换成机器码?

对的,这个过程就叫做OSR(On-Stack Replacement)。为什么叫OSR呢?我们知道JVM的底层实现是一个栈的虚拟机,所以这个替换实际上是一系列的Stack操作。

上图所示,m1方法从最初的解释frame变成了后面的compiled frame。

java并发编程 –并发问题的根源及主要解决方法

Deoptimization

这个世界是平衡的,有阴就有阳,有优化就有反优化。

小师妹:F师兄,为什么优化了之后还要反优化呢?这样对性能不是下降了吗?

通常来说是这样的,但是有些特殊的情况下面,确实是需要进行反优化的。

下面是比较常见的情况:

  1. 需要调试的情况

如果代码正在进行单个步骤的调试,那么之前被编译成为机器码的代码需要反优化回来,从而能够调试。

  1. 代码废弃的情况

当一个被编译过的方法,因为种种原因不可用了,这个时候就需要将其反优化。

  1. 优化之前编译的代码

有可能出现之前优化过的代码可能不够完美,需要重新优化的情况,这种情况下同样也需要进行反优化。

常见的编译优化举例

除了JIT编译成机器码之外,JIT还有一下常见的代码优化方式,我们来一一介绍。

Inlining内联

举个例子:

int a = 1;
int b = 2;
int result = add(a, b);
...
public int add(int x, int y) { return x + y; }
int result = a + b; //内联替换

上面的add方法可以简单的被替换成为内联表达式。

Branch Prediction分支预测

通常来说对于条件分支,因为需要有一个if的判断条件,JVM需要在执行完毕判断条件,得到返回结果之后,才能够继续准备后面的执行代码,如果有了分支预测,那么JVM可以提前准备相应的执行代码,如果分支检查成功就直接执行,省去了代码准备的步骤。

比如下面的代码:

// make an array of random doubles 0..1
double[] bigArray = makeBigArray();
for (int i = 0; i < bigArray.length; i++)
{
 double cur = bigArray[i];
 if (cur > 0.5) { doThis();} else { doThat();}
}

Loop unswitching

如果我们在循环语句里面添加了if语句,为了提升并发的执行效率,可以将if语句从循环中提取出来:

  int i, w, x[1000], y[1000];
  for (i = 0; i < 1000; i++) {
    x[i] += y[i];
    if (w)
      y[i] = 0;
  }

可以改为下面的方式:

  int i, w, x[1000], y[1000];
  if (w) {
    for (i = 0; i < 1000; i++) {
      x[i] += y[i];
      y[i] = 0;
    }
  } else {
    for (i = 0; i < 1000; i++) {
      x[i] += y[i];
    }
  }

Loop unrolling展开

在循环语句中,因为要不断的进行跳转,所以限制了执行的速度,我们可以对循环语句中的逻辑进行适当的展开:

 int x;
 for (x = 0; x < 100; x++)
 {
     delete(x);
 }

转变为:

 int x; 
 for (x = 0; x < 100; x += 5 )
 {
     delete(x);
     delete(x + 1);
     delete(x + 2);
     delete(x + 3);
     delete(x + 4);
 }

虽然循环体变长了,但是跳转次数变少了,其实是可以提升执行速度的。

Escape analysis逃逸分析

什么叫逃逸分析呢?简单点讲就是分析这个线程中的对象,有没有可能会被其他对象或者线程所访问,如果有的话,那么这个对象应该在Heap中分配,这样才能让对其他的对象可见。

如果没有其他的对象访问,那么完全可以在stack中分配这个对象,栈上分配肯定比堆上分配要快,因为不用考虑同步的问题。

我们举个例子:

  public static void main(String[] args) {
    example();
  }
  public static void example() {
    Foo foo = new Foo(); //alloc
    Bar bar = new Bar(); //alloc
    bar.setFoo(foo);
  }
}

class Foo {}

class Bar {
  private Foo foo;
  public void setFoo(Foo foo) {
    this.foo = foo;
  }
}

上面的例子中,setFoo引用了foo对象,如果bar对象是在heap中分配的话,那么引用的foo对象就逃逸了,也需要被分配在heap空间中。

但是因为bar和foo对象都只是在example方法中调用的,所以,JVM可以分析出来没有其他的对象需要引用他们,那么直接在example的方法栈中分配这两个对象即可。

逃逸分析还有一个作用就是lock coarsening。

为了在多线程环境中保证资源的有序访问,JVM引入了锁的概念,虽然锁可以保证多线程的有序执行,但是如果实在单线程环境中呢?是不是还需要一直使用锁呢?

比如下面的例子:

public String getNames() {
     Vector<String> v = new Vector<>();
     v.add("Me");
     v.add("You");
     v.add("Her");
     return v.toString();
}

Vector是一个同步对象,如果是在单线程环境中,这个同步锁是没有意义的,因此在JDK6之后,锁只在被需要的时候才会使用。

这样就能提升程序的执行效率。

总结

本文介绍了JIT的原理和一些基本的优化方式。后面我们会继续探索JIT和JVM的秘密,敬请期待。

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/jvm-jit-in-detail/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

小师妹学JVM之:深入理解JIT和编译优化-你看不懂系列
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

.Net Core微服务入门全纪录(四)——Ocelot-API网关(上)

小师妹学JVM之:JDK14中JVM的性能优化

基于 abp vNext 和 .NET Core 开发博客项目 – Blazor 实战系列(九)

目录

简介

上一篇文章我们讲到了JVM为了提升解释的性能,引入了JIT编译器,今天我们再来从整体的角度,带小师妹看看JDK14中的JVM有哪些优化的方面,并且能够从中间得到那些启发。

更多精彩内容且看:

String压缩

小师妹:F师兄,上次你给我讲的JIT真的是受益匪浅,原来JVM中还有这么多不为人知的小故事。不知道除了JIT之外,JVM还有没有其他的性能提升的姿势呢?

姿势当然有很多种,先讲一下之前提到过的,在JDK9中引入的字符串压缩。

在JDK9之前,String的底层存储结构是char[],一个char需要占用两个字节的存储单位。

因为大部分的String都是以Latin-1字符编码来表示的,只需要一个字节存储就够了,两个字节完全是浪费。

于是在JDK9之后,字符串的底层存储变成了byte[]。

目前String支持两种编码格式LATIN1和UTF16。

LATIN1需要用一个字节来存储。而UTF16需要使用2个字节或者4个字节来存储。

在JDK9中,字符串压缩是默认开启的。你可以使用

 -XX:-CompactStrings

来控制它。

分层编译(Tiered Compilation)

为了提升JIT的编译效率,并且满足不同层次的编译需求,引入了分层编译的概念。

大概来说分层编译可以分为三层:

  1. 第一层就是禁用C1和C2编译器,这个时候没有JIT进行。
  2. 第二层就是只开启C1编译器,因为C1编译器只会进行一些简单的JIT优化,所以这个可以应对常规情况。
  3. 第三层就是同时开启C1和C2编译器。

在JDK7中,你可以使用下面的命令来开启分层编译:

-XX:+TieredCompilation

而在JDK8之后,恭喜你,分层编译已经是默认的选项了,不用再手动开启。

Code Cache分层

Code Cache就是用来存储编译过的机器码的内存空间。也就说JIT编译产生的机器码,都是存放在Code Cache中的。

Code Cache是以单个heap形式组织起来的连续的内存空间。

如果只是用一个code heap,或多或少的就会引起性能问题。为了提升code cache的利用效率,JVM引入了Code Cache分层技术。

分层技术是什么意思呢?

就是把不同类型的机器码分门别类的放好,优点嘛就是方便JVM扫描查找,减少了缓存的碎片,从而提升了效率。

下面是Code Cache的三种分层:

新的JIT编译器Graal

之前的文章我们介绍JIT编译器,讲的是JIT编译器是用C/C++来编写的。

而新版的Graal JIT编译器则是用java来编写的。对的,你没看错,使用java编写的JIT编译器。

有没有一种鸡生蛋,蛋生鸡的感觉?不过,这都不重要,重要的是Graal真的可以提升JIT的编译性能。

Graal是和JDK一起发行的,作为一个内部的模块:jdk.internal.vm.compiler。

Graal和JVM是通过JVMCI(JVM Compiler Interface)来进行通信的。其中JVMCI也是一个内部的模块:jdk.internal.vm.ci。

注意,Graal只在Linux-64版的JVM中支持,你需要使用 -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler 来开启Graal特性。

详说tcp粘包和半包

前置编译

我们知道在JIT中,通常为了找到热点代码,JVM是需要等待代码执行一定的时间之后,才开始进行本地代码的编译。这样做的缺点就是需要比较长的时间。

同样的,如果是重复的代码,没有被编译成为机器码,那么对性能就会有影响。

而AOT(Ahead-of-time)就厉害了,看名字就知道是提前编译的意思,根本就不需要等待,而是在JVM启动之前就开始编译了。

AOT提供了一个java tool,名字叫做jaotc。显示jaotc的命令格式:

jaotc <options> <list of classes or jar files>
jaotc <options> <--module name>

比如,我们可以这样提前编译AOT库,以供在后面的JVM中使用:

jaotc --output libHelloWorld.so HelloWorld.class
jaotc --output libjava.base.so --module java.base

上面代码提前编译了HelloWorld和它的依赖module java.base。

然后我们可以在启动HelloWorld的时候,指定对应的lib:

java -XX:AOTLibrary=./libHelloWorld.so,./libjava.base.so HelloWorld

这样在JVM启动的时候,就回去找相应的AOTLibrary。

注意,AOT是一个 Linux-x64上面的体验功能。

压缩对象指针

对象指针用来指向一个对象,表示对该对象的引用。通常来说在64位机子上面,一个指针占用64位,也就是8个字节。而在32位机子上面,一个指针占用32位,也就是4个字节。

实时上,在应用程序中,这种对象的指针是非常非常多的,从而导致如果同样一个程序,在32位机子上面运行和在64位机子上面运行占用的内存是完全不同的。64位机子内存使用可能是32位机子的1.5倍。

而压缩对象指针,就是指把64位的指针压缩到32位。

怎么压缩呢?64位机子的对象地址仍然是64位的。压缩过的32位存的只是相对于heap base address的位移。

我们使用64位的heap base地址+ 32位的地址位移量,就得到了实际的64位heap地址。

对象指针压缩在Java SE 6u23 默认开启。在此之前,可以使用-XX:+UseCompressedOops来开启。

Zero-Based 压缩指针

刚刚讲到了压缩过的32位地址是基于64位的heap base地址的。而在Zero-Based 压缩指针中,64位的heap base地址是重新分配的虚拟地址0。这样就可以不用存储64位的heap base地址了。

Escape analysis逃逸分析

最后,要讲的是逃逸分析。什么叫逃逸分析呢?简单点讲就是分析这个线程中的对象,有没有可能会被其他对象或者线程所访问,如果有的话,那么这个对象应该在Heap中分配,这样才能让对其他的对象可见。

如果没有其他的对象访问,那么完全可以在stack中分配这个对象,栈上分配肯定比堆上分配要快,因为不用考虑同步的问题。

我们举个例子:

  public static void main(String[] args) {
    example();
  }
  public static void example() {
    Foo foo = new Foo(); //alloc
    Bar bar = new Bar(); //alloc
    bar.setFoo(foo);
  }
}

class Foo {}

class Bar {
  private Foo foo;
  public void setFoo(Foo foo) {
    this.foo = foo;
  }
}

上面的例子中,setFoo引用了foo对象,如果bar对象是在heap中分配的话,那么引用的foo对象就逃逸了,也需要被分配在heap空间中。

但是因为bar和foo对象都只是在example方法中调用的,所以,JVM可以分析出来没有其他的对象需要引用他们,那么直接在example的方法栈中分配这两个对象即可。

逃逸分析还有一个作用就是lock coarsening。

为了在多线程环境中保证资源的有序访问,JVM引入了锁的概念,虽然锁可以保证多线程的有序执行,但是如果实在单线程环境中呢?是不是还需要一直使用锁呢?

比如下面的例子:

public String getNames() {
     Vector<String> v = new Vector<>();
     v.add("Me");
     v.add("You");
     v.add("Her");
     return v.toString();
}

Vector是一个同步对象,如果是在单线程环境中,这个同步锁是没有意义的,因此在JDK6之后,锁只在被需要的时候才会使用。

这样就能提升程序的执行效率。

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/jvm-performance-enhancements/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

小师妹学JVM之:JDK14中JVM的性能优化
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

tensorflow-TFRecord 文件详解

小师妹学JVM之:JIT中的LogCompilation

对 JsonConvert 的认识太肤浅了,终于还是遇到了问题

目录

简介

我们知道在JVM中为了加快编译速度,引入了JIT即时编译的功能。那么JIT什么时候开始编译的,又是怎么编译的,作为一个高傲的程序员,有没有办法去探究JIT编译的秘密呢?答案是有的,今天和小师妹一起带大家来看一看这个编译背后的秘密。

更多精彩内容且看:

LogCompilation简介

小师妹:F师兄,JIT这么神器,但是好像就是一个黑盒子,有没有办法可以探寻到其内部的本质呢?

追求真理和探索精神是我们作为程序员的最大优点,想想如果没有玻尔关于原子结构的新理论,怎么会有原子体系的突破,如果没有海森堡的矩阵力学,怎么会有量子力学的建立?

JIT的编译日志输出很简单,使用 -XX:+LogCompilation就够了。

如果要把日志重定向到一个日志文件中,则可以使用-XX:LogFile= 。

但是要开启这些分析的功能,又需要使用-XX:+UnlockDiagnosticVMOptions。 所以总结一下,我们需要这样使用:

-XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation -XX:LogFile=www.flydean.com.log

LogCompilation的使用

根据上面的介绍,我们现场来生成一个JIT的编译日志,为了体现出专业性,这里我们需要使用到JMH来做性能测试。

JMH的全称是Java Microbenchmark Harness,是一个open JDK中用来做性能测试的套件。该套件已经被包含在了JDK 12中。

如果你使用的不是JDK 12,那么需要添加如下依赖:

<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-core</artifactId>
    <version>1.19</version>
</dependency>
<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-generator-annprocess</artifactId>
    <version>1.19</version>
</dependency>

更多详情可以参考我之前写的: 在java中使用JMH(Java Microbenchmark Harness)做性能测试一文。

之前有的朋友说,代码也用图片,看起来好看,从本文之后,我们会尽量把代码也转成图片来展示:

看完我的JMH的介绍,上面的例子应该很清楚了,主要就是做一个累加操作,然后warmup 5轮,测试5轮。

在@Fork注解里面,我们可以配置jvm的参数,为什么我注释掉了呢?因为我发现在jvmArgsPrepend中的-XX:LogFile是不生效的。

没办法,我只好在运行配置中添加:

运行之后,你就可以得到输出的编译日志文件。

解析LogCompilation文件

小师妹:F师兄,我看了一下生成的文件好复杂啊,用肉眼能看得明白吗?

别怕,只是内容的多一点,如果我们细细再细细的分析一下,你会发现其实它真的非常非常……复杂!

其实写点简单的小白文不好吗?为什么要来分析这么复杂,又没人看,看了也没人懂的JVM底层…..

大概,这就是专业吧!

LogCompilation文件其实是xml格式的,我们现在来大概分析一下,它的结构,让大家下次看到这个文件也能够大概了解它的重点。

首先最基本的信息就是JVM的信息,包括JVM的版本,JVM运行的参数,还有一些properties属性。

我们收集到的日志其实是分两类的,第一类是应用程序本身的的编译日志,第二类就是编译线程自己内部产生的日志。

第二类的日志会以hs_c*.log的格式存储,然后在JVM退出的时候,再将这些文件跟最终的日志输出文件合并,生成一个整体的日志文件。

.Net Core微服务入门全纪录(五)——Ocelot-API网关(下)

比如下面的两个就是编译线程内部的日志:

<thread_logfile thread='22275' filename='/var/folders/n5/217y_bgn49z18zvjch907xb00000gp/T//hs_c22275_pid83940.log'/>
<thread_logfile thread='41731' filename='/var/folders/n5/217y_bgn49z18zvjch907xb00000gp/T//hs_c41731_pid83940.log'/>

上面列出了编译线程的id=22275,如果我们顺着22275找下去,则可以找到具体编译线程的日志:

<compilation_log thread='22275'>
...
</compilation_log>

上面由compilation_log围起来的部分就是编译日志了。

接下来的部分表示,编译线程开始执行了,其中stamp表示的是启动时间,下图列出了一个完整的编译线程的日志:

<start_compile_thread name='C2 CompilerThread0' thread='22275' process='83940' stamp='0.058'/>

接下来描述的是要编译的方法信息:

<task compile_id='10' method='java.lang.Object <init> ()V' bytes='1' count='1409' iicount='1409' stamp='0.153'>

上面列出了要编译的方法名,compile_id表示的是系统内部分配的编译id,bytes是方法中的字节数,count表示的是该方法的调用次数,注意,这里的次数并不是方法的真实调用次数,只能做一个估计。

iicount是解释器被调用的次数。

task执行了,自然就会执行完成,执行完成的内容是以task_done标签来表示的:

<task_done success='1' nmsize='120' count='1468' stamp='0.155'/>

其中success表示是否成功执行,nmsize表示编译器编译出来的指令大小,以byte为单位。如果有内联的话,还有个inlined_bytes属性,表示inlined的字节个数。

<type id='1025' name='void'/>

type表示的是方法的返回类型。

<klass id='1030' name='java.lang.Object' flags='1'/>

klass表示的是实例和数组类型。

<method id='1148' holder='1030' name='<init>' return='1025' flags='1' bytes='1' compile_id='1' compiler='c1' level='3' iicount='1419'/>

method表示执行的方法,holder是前面的klass的id,表示的是定义该方法的实例或者数组对象。method有名字,有
return,return对应的是上面的type。

flags表示的是方法的访问权限。

接下来是parse,是分析阶段的日志:

<parse method='1148' uses='1419.000000' stamp='0.153'>

上面有parse的方法id。uses是使用次数。

<bc code='177' bci='0'/>

bc是byte Count的缩写,code是byte的个数,bci是byte code的索引。

<dependency type='no_finalizable_subclasses' ctxk='1030'/>

dependency分析的是类的依赖关系,type表示的是什么类型的依赖,ctkx是依赖的context class。

我们注意有的parse中,可能会有uncommon_trap:

<uncommon_trap bci='10' reason='unstable_if' action='reinterpret' debug_id='0' comment='taken never'/>

怎么理解uncommon_trap呢?字面上意思就是捕获非常用的代码,就是说在解析代码的过程中发现发现这些代码是uncommon的,然后解析产生一个uncommon_trap,不再继续进行了。

它里面有两个比较重要的字段,reason表示的是被标记为uncommon_trap的原因。action表示的出发uncommon_trap的事件。

有些地方还会有call:

<call method='1150' count='5154' prof_factor='1.000000' inline='1'/>

call的意思是,在该代码中将会调用其他的方法。count是执行次数。

总结

复杂的编译日志终于讲完了,可能讲的并不是很全,还有一些其他情况这里并没有列出来,后面如果遇到了,我再添加进去。

本文的例子https://github.com/ddean2009/learn-java-base-9-to-20

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/jvm-jit-logcompilation/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

小师妹学JVM之:JIT中的LogCompilation
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

基于.NetCore3.1系列 —— 认证授权方案之JwtBearer认证

区块链系列教程之:比特币的钱包与交易

Spring中基于xml的AOP

目录

简介

钱包在比特币中是做什么的呢?比特币的交易又有什么特点呢?怎么才能伪造比特币的交易呢?今天和大家一起学习一下比特币中的钱包和交易。

比特币密码学的基础

之前我们提到过比特币使用的并不是什么新技术,只是对于老的技术比如:P2P网络,分布式系统,密码学,共识算法的重新而又巧妙的应用。

在钱包和交易生成验证的过程中,都需要使用到密码学的计算。这里我们先介绍一下比特币中会使用到的几种密码学技术。

更多精彩内容且看:

单向散列函数(hash算法)

在介绍单向散列函数之前,我们先了解一下什么情况下需要使用到单向散列函数。

如果你需要从国外的网站上下载一个软件,但是因为种种原因,国外的网络太慢了,下载几个G的数据几乎是不可能的。刚好国内有镜像网站,可以从国内下载数据。但是如何保证国内的镜像不是被篡改过后的呢?这个时候就需要单向散列函数了。一般来说网站会提供MD5或者SHA的值作为验证值。

单向散列函数有一个输入和输出。输入称为消息,输出称为散列值。

散列值的长度跟消息的长度无关,不论多少大小的长度的消息,都会计算出固定长度的散列值。

hash算法有下面几个特点:

  1. 能够根据任意长度的消息计算出固定长度的散列值。

  2. 计算速度要快。

  3. 消息不同,散列值也不同。

    这就意味着,如果仅仅是一点点的变动都会引起整个散列值的巨大变化。

    因为散列值的大小是固定的,所以有可能会出现不同的消息产生相同散列值的情况。这种情况叫做碰撞。

    难以发现碰撞的性质被称为抗碰撞性。当给定某条消息的散列值时,必须保证很难找到和该消息具有相同散列值的另一条消息。

  4. 单向散列函数必须具有单向性。所谓单向性是指无法通过散列值来反推出消息的性质。

比特币使用的散列算法是SHA256,他是安全散列算法SHA(Secure Hash Algorithm)系列算法的一种(另外还有SHA-1、SHA-224、SHA-384 和 SHA-512 等变体),SHA是美国国家安全局 (NSA) 设计,美国国家标准与技术研究院(NIST) 发布的,主要适用于数字签名标准(DigitalSignature Standard DSS)里面定义的数字签名算法(Digital Signature Algorithm DSA)。

RIPEMD(RACE Integrity Primitives Evaluation Message Digest,RACE原始完整性校验消息摘要),是Hans Dobbertin等3人在md4,md5的基础上,于1996年提出来的。

非对称加密算法

非对称加密算法也叫公钥密码算法,通过生成的公私钥来对明文密文进行加密解密。

非对称加密算法需要两个密钥:公开密钥(publickey)和私有密钥(privatekey)。公开密钥与私有密钥是一对,如果用公开密钥对数据进行加密,只有用对应的私有密钥才能解密;如果用私有密钥对数据进行加密,那么只有用对应的公开密钥才能解密。因为加密和解密使用的是两个不同的密钥,所以这种算法叫作非对称加密算法。

扩展阅读:同态加密

同态加密是一种加密形式,它允许人们对密文进行特定的代数运算得到仍然是加密的结果,将其解密所得到的结果与对明文进行同样的运算结果一样。换言之,这项技术令人们可以在加密的数据中进行诸如检索、比较等操作,得出正确的结果,而在整个处理过程中无需对数据进行解密。其意义在于,真正从根本上解决将数据及其操作委托给第三方时的保密问题,例如对于各种云计算的应用。

密钥,地址和钱包

比特币的所有权是通过数字密钥、比特币地址和数字签名来确立的。数字密钥实际上并不是存储在网络中,而是由用户生成并存储在一个文件或简单的数据库 中,称为钱包。存储在用户钱包中的数字密钥完全独立于比特币协议,可由用户的钱包软件生成并管理,而无需区块链或网络连接。密钥实现了比特币的许多有趣特性,包括去中心化信任和控制、所有权认证和基于密码学证明的安全模型。

比特币钱包只包含私钥而不是比特币。每一个用户有一个包含多个私钥的钱包。钱包中包含成对的私钥和公钥。用户用这些私钥来签名交易,从而证明它们拥有交易的输出(也就是其中的比特币)。比特币是以交易输出的形式来储存在区块链中(通常记为vout或txout)。

如果钱包只包含私钥,那么钱包地址是什么呢?钱包地址是从公钥的hash值的出来的,如下图所示:

  1. 首先使用随机数发生器生成一个『私钥』。一般来说这是一个256bits的数,拥有了这串数字就可以对相应『钱包地址』中的比特币进行操作,所以必须被安全地保存起来。

  2. 『私钥』经过SECP256K1算法处理生成了『公钥』。SECP256K1是一种椭圆曲线算法,通过一个已知『私钥』时可以算得『公钥』,而『公钥』已知时却无法反向计算出『私钥』。这是保障比特币安全的算法基础。

  3. 同SHA256一样,RIPEMD160也是一种Hash算法,由『公钥』可以计算得到『公钥哈希』,而反过来是行不通的。

  4. 将一个字节的地址版本号连接到『公钥哈希』头部(对于比特币网络的pubkey地址,这一字节为“0”),然后对其进行两次SHA256运算,将结果的前4字节作为『公钥哈希』的校验值,连接在其尾部。

  5. 将上一步结果使用BASE58进行编码(比特币定制版本),就得到了『钱包地址』。 比如,1A1zP1eP5QGefi2DMPTfTL5TTmv7DivfNa。

所以私钥,公钥和钱包地址的关系如下图所示:

大家看到钱包地址1A1zP1eP5QGefi2DMPTfTL5TTmv7DivfNa有什么想法呢?

肯定有人在想,这么一大长串字母和数字实在是太不好记忆了。能不能生产一个比较好记的钱包地址呢? 比如MyNameIsHanMeiMei….这样开头的地址呢?

当然可以,这叫做靓号地址,只不过需要大量的算力才行。

比特币中的交易

简单来说,交易就是告知全网:比特币的持有者已授权把比特币转帐给其他人。而新持有者能够再次授权,转移给该比特币所有权链中的其他人。

注意, 在比特币的世界里既没有账户,也没有余额,只有分散到区块链里的UTXO(Unspent Transaction Outputs)。

深入了解C#(TPL)之Parallel.ForEach异步

怎么理解这个UTXO呢?没有账户也没有余额,那么钱包里面的金额是怎么计算出来的呢?

别急,让我们一一道来。

话说,在比特币中,比特币钱包间的转账是通过交易(Transaction)实现的。

我们看一个标准的交易流程。

那么问题来了,世界上第一个比特币是哪里来的呢?

答,是挖矿来的。好了,我们的001交易表示的就是一个挖矿的过程,在这个交易中,输入就是挖矿,输出编号1,BTC数目是50,目的地址是A,表示这50个BTC给A了。

接下来,A想发25个BTC给B,怎么构造这个交易呢?

同样的,我们需要一个输入,这个输入就是001交易的1号输出,我们用001.1来表示。输出分为两个,第一个输出编号1,表示要付25个BTC给B。第二个输出编号2,表示剩下的BTC要还给A。

大家可能会问了,输入是50BTC,两个输出加起来才45个BTC,好像还少了5个BTC?没错,这个5个BTC就是给矿工的挖矿所得。

接下来,A又继续转账给C,同样的道理,把一个一个的交易连接起来。

从上面的例子我们可以看到,实际上钱是存在一个一个的交易记录里面的,那些未被花费的输出,就叫做UTXO(Unspent Transaction Outputs)。

那么怎么保证转账给B的钱,不会被其他的人消费呢?这就涉及到交易的加密过程了。

我们以单个输入和输出为例来详细了解一下交易的构成:

上图中,交易的输入就是txid,也就是之前生成的还有未花费暑输出的交易ID。output index就是交易的输出id。

一个非常重要的ScriptSig是输入交易的验证,表明这个用户拥有这个账户的转账权限。

输出是一个脚本,只有满足脚本运行条件的人才能花费这个output。这也就是ScriptSig需要验证的脚本。

我们看下脚本是怎么做认证的吧。

比特币的标准输出形式有两种。Pay To Public Key Hash (P2PKH) 和 Pay To Script Hash (P2SH)。两者的区别在于,一个是输出到public key的hash,一个是输出到任意的一个脚本输出hash。

为了保证输出只能由特定的人来花费,一般的情况下是直接输出到对方的public key hash。由于只有对方拥有的私钥能够生成这个public key hash,也就是说只有对方才能够对这个输出进行验证。

但每次都需要知道对方的public key hash还是比较麻烦的,更简单的做法就是,发送者直接输出到一个特定的hash值就行了,只要对方能够生成这个hash就可以。

下面的例子是一个P2PKH的脚本形式。

P2PKH的输出是一个脚本,里面一个重要的值就是PK hash。

怎么验证呢?

验证方提供两个值,一个是sig,一个是PubKey。因为比特币的虚拟机是栈结构的,我们先把这两个值入栈。

然后调用OP_DUP对最上层的PubKey进行拷贝,然后调用OP_HASH160算法来计算Pk Hash,然后将发送方保存的Pk Hash入栈。接下来调用OP_EQUALVERIFY对两个PK Hash进行对比。

如果对比成功,最后一步就是验证Sig和PubKey是否匹配。

如果都成功,说明接收方的确是这个PK Hash的拥有者。那么对方就可以尽情使用了。

扩展阅读:图灵非完备性

和冯·诺伊曼同为现代计算机奠基人的阿兰·图灵(AlanTurin)在1950年提出了判定计算机能否像人那般实际“思考”的标准,也就是著名的“图灵检验”。

他设想一台超级计算机和一个人躲藏在幕后回答提问者的问题,而提问者则试图分辨哪个是人哪个是计算机。

图灵争辩说,假如计算机伪装得如此巧妙,以致没有人可以在实际上把它和一个真人分辨开来的话,那么我们就可以声称,这台计算机和人一样具备了思考能力,或者说,意识(他的原词是“智慧”)。

在可计算性理论里,如果一系列操作数据的规则(如指令集、编程语言、细胞自动机)按照一定的顺序可以计算出结果,被称为图灵完备(turing complete)。

比特币脚本语言不是图灵完备的,具有一定的局限性,它没有循环语句和复杂的条件控制语句。

总结

本文介绍了比特币的钱包和交易的概念,希望大家能够喜欢。

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/bitcoin-transactions/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

区块链系列教程之:比特币的钱包与交易
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

【服务器】VMware Workstation Pro虚拟机搭建本地服务器CentOs7和宝塔面板(保姆式教程)

区块链系列教程之:比特币中的网络和区块链

基于领域驱动设计(DDD)超轻量级快速开发架构,ASP.NET MVC 5 SmartCode Scaffolding for Visual Studio.Net

目录

简介

比特币的底层就是区块链技术,区块链也是因为比特币而广为人知的。和其他的区块链技术相比,比特币的区块链有什么特征呢?作为去区块链的鼻祖,又有什么与众不同的特性呢?快来跟我们一起看看吧。

比特币的网络

比特币使用的是P2P(peer-to-peer)网络,此P2P非彼P2P,这里是点对点的网络架构,而不是人对人的借钱模式。

P2P是指位于同一网络中的每台计算机都彼此对等,各个节点共同提供网络服务,不存在任何“特殊”节点。每个网络节点以“扁平(flat)”的拓扑结构相互连通。在P2P网络中不存在任何服务端(server)、中央化的服务、以及层级结构。

传统的网络结构是client-server的模式,所有的client都是和server交互获取信息, 只要server挂掉了,client也就没有用了。

而在P2P网络中,没有server的概念,每个节点可以作为一个server。对比起来P2P网络在稳定性方面要比C-S架构的系统要稳定得多。

网络发现与同步

既然是P2P网络,那么问题来了,这个P2P网络是怎么建立起来的呢?节点之间是怎么发现的呢?

有做过P2P下载的同学应该都听说过种子的概念,这个种子里面保存了其他活跃的节点的地址。通过下载种子就可以连接对应的节点。

而每个节点又保存了最近连接或者活跃的节点,这样就形成了庞大的P2P网络。

同样的,比特币的P2P网络也是这样的。

新节点是如何发现网络中的对等节点的呢?虽然比特币网络中没有特殊节点,但是客户端会维持一个列表,那里列出了那些长期稳定运行的节点。这样的节点被称为“种子节点(seed nodes)”

节点必须持续进行两项工作:在失去已有连接时发现新节点,并在其他节点启动时为其提供帮助。

SPV节点

我们之前介绍了,在比特币的世界里既没有账户,也没有余额,只有分散到区块链里的UTXO(Unspent Transaction Outputs)。

那么如果想要验证交易的话,需要从历史的交易中查找所有的和该交易有关的交易,从而进行完整,全面的验证。

这样做的问题就是,如果下载所有的历史记录,那么需要上百G的硬盘空间,这对于手机或者其他轻量级的客户端是无法想象的。

于是SPV出现了。SPV的全称是Simplified payment verification,叫做简单认证支付。

SPV保存的不是整个区块链,而是区块链的头部,因为每个区块链头只有80字节,所以即使把所有的区块头都下载保存起来也不会很大。

区块链头

区块头由三组区块元数据组成。首先是一组引用父区块哈希值的数据,这组元数据用于将该区块与区块链中前一区块相连接。

第二组元数据,即难度、时间戳和nonce,与挖矿竞争相关。

第三组元数据是merkle树根(一种用来有效地总结区块中所有交易的数据结构)。

Nonce、难度目标和时间戳会用于挖矿过程,Merkle根用来索引和组织该区块所有的交易信息。

上图是一个区块链头组成的链。

Merkle Tree

Merkle Tree,是一种树(数据结构中所说的树),网上大都称为Merkle Hash Tree,这是因为 它所构造的Merkle Tree的所有节点都是Hash值。Merkle Tree具有以下特点:

Elasticsearch系列—生产集群的索引管理

  1. 它是一种树,可以是二叉树,也可以多叉树,无论是几叉树,它都具有树结构的所有特点;

  2. Merkle树的叶子节点上的value,是由你指定的,这主要看你的设计了,如Merkle Hash Tree会将数据的Hash值作为叶子节点的值;

  3. 非叶子节点的value是根据它下面所有的叶子节点值,然后按照一定的算法计算而得出的。如Merkle Hash Tree的非叶子节点value的计算方法是将该节点的所有子节点进行组合,然后对组合结果进行hash计算所得出的hash value。

有了Merkle Tree,我们只需要知道和要验证的交易相关的其他Merkle Tree中的信息,就可以计算出整个Merkle Tree的值,这样就可以直接使用头部信息进行验证了。这就是SPV的原理。

比特币中的区块链

区块链是由包含交易信息的区块从后向前有序链接起来的数据结构。它可以被存储为flat file(一种包含没有相对关系记录的文件),或是存储在一个简单数据库中。

比特币核心客户端使用Google的LevelDB数据库存储区块链元数据。

它由一个包含元数据的区块头和紧跟其后的构成区块主体的一长串交易组成。区块头是80字节,而平均每个交易至少是250字节,而且平均每个区块至少包含超过500个交易。

区块标识符

那怎么表示一个区块呢?我们使用区块标志符。

区块主标识符是它的加密哈希值,一个通过SHA256算法对区块头进行二次哈希计算而得到的数字指纹。产生的32字节哈希值被称为区块哈希值,但是更准确的名称是:区块头哈希值,因为只有区块头被用于计算。

第二种识别区块的方式是通过该区块在区块链中的位置,即“区块高度(block height)”。第一个区块,其区块高度为0
和区块哈希值不同的是,区块高度并不是唯一的标识符。虽然一个单一的区块总是会有一个明确的、固定的区块高度,但反过来却并不成立,一个区块高度并不总是识别一个单一的区块。两个或两个以上的区块可能有相同的区块高度,在区块链里争夺同一位置。

创世区块

区块链里的第一个区块创建于2009年,被称为创世区块。它是区块链里面所有区块的共同祖先,这意味着你从任一区块,循链向后回溯,最终都将到达创世区块。

因为创世区块被编入到比特币客户端软件里,所以每一个节点都始于至少包含一个区块的区块链,这能确保创世区块不会被改变。每一个节点都“知道”创世区块的哈希值、结构、被创建的时间和里面的一个交易。因此,每个节点都把该区块作为区块链的首区块,从而构建了一个安全的、可信的区块链的根。

创世区块的哈希值为:
0000000000 19d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

创世区块包含一个隐藏的信息。在其Coinbase交易的输入中包含这样一句话“The Times 03/Jan/2009 Chancellor on brink of second bailout forbanks.”这句话是泰晤士报当天的头版文章标题,引用这句话,既是对该区块产生时间的说明,也可视为半开玩笑地提醒人们一个独立的货币制度的重要性,同时告诉人们随着比特币的发展,一场前所未有的世界性货币革命将要发生。该消息是由比特币的创立者中本聪嵌入创世区块中。

coinbase的值是:04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73

解码方法如下:

在python shell下:

“04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73”.decode(‘hex’)

输出:

‘\x04\xff\xff\x00\x1d\x01\x04EThe Times 03/Jan/2009 Chancellor on brink of second bailout for banks’

总结

本文介绍了比特币的网络和比特币中的区块链的相关概念,希望大家能够喜欢。

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/bitcoin-blockchain-network/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

区块链系列教程之:比特币中的网络和区块链
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

三文搞懂学会Docker容器技术(中)

八张图彻底了解JDK8 GC调优秘籍-附PDF下载

Newtonsoft 六个超简单又实用的特性,值得一试 【下篇】

目录

简介

JVM的参数有很多很多,根据我的统计JDK8中JVM的参数总共有1853个,正式的参数也有680个。

这么多参数带给我们的是对JVM的细粒度的控制,但是并不是所有的参数都需要我们自己去调节的,我们需要关注的是一些最常用的,对性能影响比较大的GC参数即可。

为了更好的让大家理解JDK8中 GC的调优的秘籍,这里特意准备了八张图。在本文的最后,还附带了一个总结的PDF all in one文档,大家把PDF下载回去,遇到问题就看两眼,不美吗?

分代垃圾回收器的内存结构

为了更好的提升GC的效率,现代的JVM都是采用的分代垃圾回收的策略(ZGC不是)。

java运行时内存可以分为JVM内存和非JVM内存。

JVM内存又可以分为堆内存和非堆内存。

堆内存大家都很熟悉了,YoungGen中的Eden,Survivor和OldGen。

非堆内存中存储的有thread Stack,Code Cache, NIO Direct Buffers,Metaspace等。

注意这里的Metaspace元空间是方法区在JDK8的实现,它是在本地内存中分配的。

JDK8中可用的GC

JDK8中到底有哪些可以使用的GC呢?

这里我们以HotSpot JVM为例,总共可以使用4大GC方式:

其中对于ParallelGC和CMS GC又可以对年轻代和老年代分别设置GC方式。

大家看到上图可能有一个疑问,Parallel scavenge和Parallel有什么区别呢?

其实这两个GC的算法是类似的,Parallel Scavenge收集器也经常称为“吞吐量优先”收集器,Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量; -XX:MaxGCPauseMillis:控制最大垃圾收集停顿时间; -XX:GCTimeRatio:设置吞吐量大小。

同时Parallel Scavenge收集器能够配合自适应调节策略,把内存管理的调优任务交给虚拟机去完成。

JDK8中默认开启的是ParallelGC。

打印GC信息

如果想研究和理解GC的内部信息,GC信息打印是少不了的:

上图提供了一些非常有用的GC日志的控制参数。

内存调整参数

JVM分为Heap区和非Heap区,各个区又有更细的划分,下面就是调整各个区域大小的参数:

谁再悄咪咪的吃掉异常,我上去就是一 JIO

Thread配置

TLAB大家还记得吗?TLAB的全称是Thread-Local Allocation Buffers。TLAB是在Eden区间分配的一个一个的连续空间。然后将这些连续的空间分配个各个线程使用。

因为每一个线程都有自己的独立空间,所以这里不涉及到同步的概念。

上图就是TLAB的参数。

通用GC参数

虽然JDK8的GC这么多,但是他们有一些通用的GC参数:

这里讲解一下Young space tenuring,怎么翻译我不是很清楚,这个主要就是指Young space中的对象经过多少次GC之后会被提升到Old space中。

CMS GC

CMS全称是Concurrent mark sweep。是一个非常非常复杂的GC。

复杂到什么程度呢?光光是CMS调优的参数都有一百多个!

下图是常用的CMS的参数。

CMS这里就不多讲了,因为在JDK9之后,CMS就已经被废弃了。

主要原因是CMS太过复杂,如果要向下兼容需要巨大的工作量,然后就直接被废弃了。

在JDK9之后,默认的GC是G1。

G1参数

G1收集器是分代的和region化的,也就是整个堆内存被分为一系列大小相等的region。在启动时,JVM设置region的大小,根据堆大小的不同,region的大小可以在1MB到32MB之间变动,region的数量最多不超过2048个。Eden区、Survivor区、老年代是这些region的逻辑集合,它们并不是连续的。

G1中的垃圾收集过程:年轻代收集和混合收集交替进行,背后有全局的并发标记周期在进行。当老年代分区占用的空间达到或超过初始阈值,就会触发并发标记周期。

下图是G1的调优参数:

总结

上面总共8副图,我把他们做成了一个PDF,预览界面大概是这样子的:

大家可以通过下面的链接直接下载PDF版本:

JDK8GC-cheatsheet.pdf

如果遇到问题可以直接拿过来参考。这种东西英文名字应该叫JDK8 GC cheatsheet,翻译成中文应该就是JDK8 GC调优秘籍!

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/jdk8-gc-cheatsheet/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

八张图彻底了解JDK8 GC调优秘籍-附PDF下载
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

恕我直言你可能真的不会java第5篇:Stream的状态与并行操作

小师妹学JVM之:JIT中的PrintCompilation

数据库char varchar nchar nvarchar,编码Unicode,UTF8,GBK等,Sql语句中文前为什么加N(一次线上数据存储乱码排查)

目录

简介

上篇文章我们讲到了JIT中的LogCompilation,将编译的日志都收集起来,存到日志文件里面,并且详细的解释了LogCompilation日志文件中的内容定义。今天我们再和小师妹一起学习LogCompilation的姊妹篇PrintCompilation,看看都有什么妙用吧。

PrintCompilation

小师妹:F师兄,上次你给讲的LogCompilation实在是太复杂了,生成的日志文件又多,完全看不了,我其实只是想知道有哪些方法被编译成了机器码,有没有什么更加简单的办法呢?

真理的大海,让未发现的一切事物躺卧在我的眼前,任我去探寻- 牛顿(英国)

当然有的,那就给你介绍一下LogCompilation的妹妹PrintCompilation,为什么是妹妹呢?因为PrintCompilation输出的日志要比LogCompilation少太多了。

老规矩,上上我们的JMH运行代码,文章中使用的代码链接都会在文末注明,这里使用图片的原因只是为了方便读者阅读代码:

这里和上次的LogCompilation不同的是,我们使用:-XX:+PrintCompilation参数。

其实我们还可以添加更多的参数,例如:

-Xbatch -XX:-TieredCompilation -XX:+PrintCompilation

先讲一下-Xbatch。

一般来说JIT编译器使用的是和主线程完全不同的新的线程。这样做的好处就是JIT可以和主线程并行执行,编译器的运行基本上不会影响到主线程的的运行。

但是有阴就有阳,有利就有弊。多线程在提高的处理速度的同时,带给我们的就是输出日志的混乱。因为是并行执行的,我们主线程的日志中,穿插了JIT编译器的线程日志。

如果使用-Xbatch就可以强迫JIT编译器使用主线程。这样我们的输出日志就是井然有序的。真棒。

再讲一下TieredCompilation。

为了更好的提升编译效率,JVM在JDK7中引入了分层编译Tiered compilation的概念。

大概来说分层编译可以分为三层:

第一层就是禁用C1和C2编译器,这个时候没有JIT进行。
第二层就是只开启C1编译器,因为C1编译器只会进行一些简单的JIT优化,所以这个可以应对常规情况。
第三层就是同时开启C1和C2编译器。

在JDK8中,分层编译是默认开启的。因为不同的编译级别处理编译的时间是不一样的,后面层级的编译器启动的要比前面层级的编译器要慢,但是优化的程度更高。

这样我们其实会产生很多中间的优化代码,这里我们只是想分析最终的优化代码,所以我们需要停止分层编译的功能。

最后是今天的主角:PrintCompilation。

PrintCompilation将会输出被编译方法的统计信息,因此使用PrintCompilation可以很方便的看出哪些是热点代码。热点代码也就意味着存在着被优化的可能性。

一起玩转微服务(12)——揭密starter

分析PrintCompilation的结果

小师妹:F师兄,我照着你的例子运行了一下,结果果然清爽了很多。可是我还是看不懂。

没有一个人能全面把握真理。小师妹,我们始终在未知的路上前行。不懂就问,不会就学。

我们再截个图看一下生成的日志吧。

因为日志太长了,为了节约大家的流量,我只截取了开头的部分和结尾的部分。

大家可以看到开头部分基本上都是java自带的类的优化。只有最后才是我们自己写的类。

第一列是方法开始编译的时间。

第二列是简单的index。

第三列是一系列的flag的组合,有下面几个flag:

b    Blocking compiler (always set for client)
*    Generating a native wrapper
%    On stack replacement (where the compiled code is running)
!    Method has exception handlers
s    Method declared as synchronized
n    Method declared as native
made non entrant    compilation was wrong/incomplete, no future callers will use this version
made zombie         code is not in use and ready for GC

如果我们没有关闭分层编译的话,在方法名前面还会有数字,表示是使用的那个编译器。

分层编译详细的来说可以分为5个级别。

0表示是使用解释器,不使用JIT编译。
1,2,3是使用C1编译器(client)。
4是使用C2编译器(server)。

现在让我们来看一下最后一列。

最后一列包含了方法名和方法的长度。注意这里的长度指的是字节码的长度。

如果字节码被编译成为机器码,长度会增加很多倍。

总结

本文介绍了JIT中PrintCompilation的使用,并再次复习了JIT中的分层编译架构。希望大家能够喜欢。

本文的例子https://github.com/ddean2009/learn-java-base-9-to-20

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/jvm-jit-printcompilation/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

小师妹学JVM之:JIT中的PrintCompilation
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

那些年,我们用过的服务器软件

小师妹学JVM之:java的字节码byte code简介

Spring7——开发基于注解形式的spring

目录

简介

Byte Code也叫做字节码,是连接java源代码和JVM的桥梁,源代码编译成为字节码,而字节码又被加载进JVM中运行。字节码怎么生成,怎么查看字节码,隐藏在Byte Code背后的秘密是什么呢?快跟小师妹一起来看看吧。

Byte Code的作用

小师妹:F师兄,为什么Java需要字节码呢?直接编译成为机器码不是更快吗?

小师妹,Java的设计初衷是一次编写,到处运行。为了兼容各个平台的运行环境,java特别为各种平台设计了JVM。

我们可以把JVM看做是一种抽象,对外提供了统一的接口。这样我们只需要编写符合JVM规范的代码,即可在JVM中运行。

回想下之前我们提到过的java的执行过程:

  1. 编写java代码文件比如Example.java
  2. 使用java编译器javac将源文件编译成为Example.class文件
  3. JVM加载生成的字节码文件,将其转换成为机器可以识别的native machine code执行

小师妹:F师兄,我有一个大胆的想法,JVM的作用是将字节码解释或者编译成为机器码。然后在相应的运行环境中执行。那么有没有可能,不需要JVM,不需要机器码,而是直接在对应的平台上执行字节码呢?

爱因斯坦说过没有想像力的灵魂,就像没有望远镜的天文台。小师妹你这个想法很好,这种实现有个专业的说法叫做:Java processor。

Java processor就是用硬件来实现的JVM。因此字节码可以直接在Java processor中运行。

其中比较出名的是Jazelle DBX,这是一个主要支持J2ME环境的硬件架构。为了提升java在手机端的执行速度。

但是这样做其实也是有缺点的,后面我们会讲到,java字节码中的指令非常非常多。所以如果用硬件来实现的话,就会非常非常复杂。

一般来说Java processor不会实现全部的字节码中的功能,只会提供部分的实现。

查看Byte Code字节码

小师妹:F师兄,那使用javac编译过后的class文件跟字节码有什么关系呢?

class文件中大部分都是byte code,其他的部分是一些meta data元数据信息。这些组合在一起就是class文件了。

小师妹:F师兄,你说class文件是byte code,为什么我在IDE中打开的时候,直接显示的是反编译出来的源文件呢?

小师妹,这是IDE的一个便利功能。因为大多数情况下,没有人想去看class文件的Byte code的,大家都是想去看看这个class文件的源文件是什么样的。

我们举个最简单的例子:

这个类中,我们定义了一个很简单的testByteCode方法,里面定义了两个变量,然后返回他们两个的和。

现在有两种方法来查看这个类的Byte Code:

第一种方法是用javap命令:

javap -c ByteCodeUsage.class

生成的结果如上所示。

第二种方法就是在IDEA中,选中class文件,然后在view中选中show Bytecode:

Spring Boot2+Resilience4j实现容错之Bulkhead

我们看下输出结果:

两个的结果在显示上面可能有细微的差异,但是并不影响我们后面对其的解析。

java Byte Code是怎么工作的

小师妹:F师兄,能讲解一下这些byte code到底是怎么工作的吗?

首先我们要介绍一下JVM的实现是基于栈的结构的。为什么要基于栈的结构呢?那是因为栈是最适合用来实现function互相调用的。

我们再回顾一下上面的testByteCode的字节码。里面有很多iconst,istore的东西,这些东西被称作Opcode,也就是一些基于栈的操作指令。

上面讲了java bytecode的操作指令其实有很多个。下面我们列出这些指令的部分介绍:

实在是太多了,这里就不把所有的列出来了。

我们看到的指令名字其实是一个助记词,真实的Opcode是一个占用两个字节的数字。

下面我们来详细解释一下testByteCode方法:

public int testByteCode();
    Code:
       0: iconst_1
       1: istore_1
       2: iconst_2
       3: istore_2
       4: iload_1
       5: iload_2
       6: iadd
       7: ireturn

第一步,iconst_1将int 1加载到stack中。

第二步,istore_1将入栈的int 1出栈,并存储到变量1中。

第三步,iconst_2将int 2入栈。

第四步,istore_2将入栈的int 2出栈,并存储到变量2中。

第五步,iload_1将变量1中的值入栈。

第六步,iload_2将变量2中的值入栈。

第七步,iadd将栈中的两个变量出栈,并相加。然后将结果入栈。

第八步,ireturn将栈中的结果出栈。

这几步实际上完美的还原了我们在testByteCode方法中定义的功能。

当然我们只介绍了最贱的byte code命令,通过这些简单的命令可以组合成为更加复杂的java命令。

总结

本文介绍了java byte code的作用和具体的指令,并分析了一个简单的例子来做说明。希望大家能够掌握。

本文的例子https://github.com/ddean2009/learn-java-base-9-to-20

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/jvm-byte-code/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

小师妹学JVM之:java的字节码byte code简介
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

多线程高并发编程(12) — 阻塞算法实现ArrayBlockingQueue源码分析

小师妹学JVM之:逃逸分析和TLAB

DevOps研发模式下「产品质量度量」方案实践

目录

简介

逃逸分析我们在JDK14中JVM的性能优化一文中已经讲过了,逃逸分析的结果就是JVM会在栈上分配对象,从而提升效率。如果我们在多线程的环境中,如何提升内存的分配效率呢?快来跟小师妹一起学习TLAB技术吧。

逃逸分析和栈上分配

小师妹:F师兄,从前大家都说对象是在堆中分配的,然后我就信了。上次你居然说可以在栈上分配对象,这个实在是颠覆了我一贯的认知啊。

柏拉图说过:思想永远是宇宙的统治者。只要思想不滑坡,办法总比困难多。别人告诉你的都是一些最基本,最最通用的情况。而师兄我告诉你的则是在优化中的特列情况。

小师妹:F师兄,看起来JVM在提升运行速度方面真的做了不少优化呀。

是呀,Java从最开始被诟病速度慢,到现在执行速度直追C语言。这些运行时优化是必不可少的。还记得我们之前讲的逃逸分析是怎么回事吗?

小师妹:F师兄,这个我知道,如果一个对象的分配是在方法内部,并且没有多线程访问的情况下,那么这个对象其实可以看做是一个本地对象,这样的对象不管创建在哪里都只对本线程中的本方法可见,因此可以直接分配在栈空间中。

对的,栈上分配的对象因为不用考虑同步,所以执行速度肯定会更加快速,这也是为什么JVM会引入栈上分配的原因。

再举一个形象直观的例子。工厂要组装一辆汽车,在buildCar的过程中,需要先创建一个Car对象,然后给它按上轮子。

  public static void main(String[] args) {
    buildCar();
  }
  public static void buildCar() {
    Wheel whell = new Wheel(); //分配轮子
    Car car = new Car(); //分配车子
    car.setWheel(whell);
  }
}

class Wheel {}

class Car {
  private Wheel whell;
  public void setWheel(Wheel whell) {
    this.whell = whell;
  }
}

考虑一下上面的情况,如果假设该车间是一个机器人组装一台车,那么上面方法中创建的Car和Wheel对象,其实只会被这一个机器人访问,其他的机器人根本就不会用到这个车的对象。那么这个对象本质上是对其他机器人隐形的。所以我们可以不在公共空间分配这个对象,而是在私人的栈空间中分配。

逃逸分析还有一个作用就是lock coarsening。同样的,单线程环境中,锁也是不需要的,也可以优化掉。

TLAB简介

小师妹:F师兄,我觉得逃逸分析很好呀,栈上分配也不错。既然又这么厉害的两项技术了,为什么还要用到TLAB呢?

首先这是两个不同的概念,TLAB的全称是Thread-Local Allocation Buffers。Thread-Local大家都知道吧,就是线程的本地变量。而TLAB则是线程的本地分配空间。

逃逸分析和栈上分配只是争对于单线程环境来说的,如果在多线程环境中,不可避免的会有多个线程同时在堆空间中分配对象的情况。

这种情况下如何处理才能提升性能呢?

小师妹:哇,多个线程竞争共享资源,这不是一个典型的锁和同步的问题吗?

锁和同步是为了保证整个资源一次只能被一个线程访问,我们现在的情况是要在资源中为线程划分一定的区域。这种操作并不需要完全的同步,因为heap空间够大,我们可以在这个空间中划分出一块一块的小区域,为每个线程都分一块。这样不就解决了同步的问题了吗?这也可以称作空间换时间。

TLAB详解

小师妹,还记得heap分代技术中的一个中心两个基本点吗?哦,1个Eden Space和2个Suvivor Space吗?

Young Gen被划分为1个Eden Space和2个Suvivor Space。当对象刚刚被创建的时候,是放在Eden space。垃圾回收的时候,会扫描Eden Space和一个Suvivor Space。如果在垃圾回收的时候发现Eden Space中的对象仍然有效,则会将其复制到另外一个Suvivor Space。

就这样不断的扫描,最后经过多次扫描发现任然有效的对象会被放入Old Gen表示其生命周期比较长,可以减少垃圾回收时间。

因为TLAB关注的是新分配的对象,所以TLAB是被分配在Eden区间的,从图上可以看到TLAB是一个一个的连续空间。

然后将这些连续的空间分配个各个线程使用。

因为每一个线程都有自己的独立空间,所以这里不涉及到同步的概念。默认情况下TLAB是开启的,你可以通过:

-XX:-UseTLAB

来关闭它。

设置TLAB空间的大小

小师妹,F师兄,这个TLAB的大小是系统默认的吗?我们可以手动控制它的大小吗?

要解决这个问题,我们还得去看JVM的C++实现,也就是threadLocalAllocBuffer.cpp:

比Minikube更快,使用Kind快速创建K8S学习环境

上面的代码可以看到,如果设置了TLAB(默认是0),那么TLAB的大小是定义的TLABSize除以HeapWordSize和max_size()中最小的那个。

HeapWordSize是heap中一个字的大小,我猜它=8。别问我为什么,其实我也是猜的,有人知道答案的话可以留言告诉我。

TLAB的大小可以通过:

-XX:TLABSize

来设置。

如果没有设置TLAB,那么TLAB的大小就是分配线程的平均值。

TLAB的最小值可以通过:

-XX:MinTLABSize

来设置。

默认情况下:

-XX:ResizeTLAB

resize开关是默认开启的,那么JVM可以对TLAB空间大小进行调整。

TLAB中大对象的分配

小师妹:F师兄,我想到了一个问题,既然TLAB是有大小的,如果一个线程中定义了一个非常大的对象,TLAB放不下了,该怎么办呢?

好问题,这种情况下又有两种可能性,我们假设现在的TLAB的大小是100K:

第一种可能性:

目前TLAB被使用了20K,还剩80K的大小,这时候我们创建了一个90K大小的对象,现在90K大小的对象放不进去TLAB,这时候需要直接在heap空间去分配这个对象,这种操作实际上是一种退化操作,官方叫做 slow allocation。

第二中个可能性:

目前TLAB被使用了90K,还剩10K大小,这时候我们创建了一个15K大小的对象。

这个时候就要考虑一下是否仍然进行slow allocation操作。

因为TLAB差不多已经用完了,为了保证后面new出来的对象仍然可以有一个TLAB可用,这时候JVM可以尝试将现在的TLAB Retire掉,然后分配一个新的TLAB空间,把15K的对象放进去。

JVM有个开关,叫做:

-XX:TLABWasteTargetPercent=N

这个开关的默认值是1。表示如果新分配的对象大小如果超出了设置的这个百分百,那么就会执行slow allocation。否则就会分配一个新的TLAB空间。

同时JVM还定义了一个开关:

-XX:TLABWasteIncrement=N

为了防止过多的slow allocation,JVM定义了这个开关(默认值是4),比如说第一次slow allocation的极限值是1%,那么下一次slow allocation的极限值就是%1+4%=5%。

TLAB空间中的浪费

小师妹:F师兄,如果新分配的TLAB空间,那么老的TLAB中没有使用的空间该怎么办呢?

这个叫做TLAB Waste。因为不会再在老的TLAB空间中分配对象了,所以剩余的空间就浪费了。

总结

本文介绍了逃逸分析和TLAB的使用。希望大家能够喜欢。

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/jvm-escapse-tlab/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

小师妹学JVM之:逃逸分析和TLAB
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

一文说通MongoDB via Python操作

小师妹学JVM之:JIT中的PrintAssembly续集

多线程下的list

目录

简介

上篇文章和小师妹一起介绍了PrintAssembly和PrintAssembly在命令行的使用,今天本文将会更进一步讲解如何在JDK8和JDK14中分别使用PrintAssembly,并在实际的例子中对其进行进一步的深入理解。

JDK8和JDK14中的PrintAssembly

小师妹:F师兄,上次你介绍的PrintAssembly的自测命令,怎么在JDK14中不好用呢?

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -version

有什么不好用的,命令不是正常打出来了吗?

小师妹:F师兄,你看下我运行的结果,机器码下面展示的怎么是448b 5608这样的数字呀,不应该是assembly language吗?

嗯…小师妹的话让我陷入了深深的思考,究竟是什么导致了这样的反常的结果呢?是道德的沦丧还是人性的扭曲?

于是我翻遍了baidu,哦,不对是google,还是没有找到结果。

难点是JDK14有bug?还是JDK14已经使用了另外的Assembly的实现?

有问题就解决问题,我们先从JDK8开始,来探索一下最原始的PrintAssembly的使用。

更多精彩内容且看:

JDK8中使用Assembly

在JDK8中如果我们运行Assembly的测试命令,可以得到下面的结果:

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -version

Java HotSpot(TM) 64-Bit Server VM warning: PrintAssembly is enabled; turning on DebugNonSafepoints to gain additional output
Could not load hsdis-amd64.dylib; library not loadable; PrintAssembly is disabled
java version "1.8.0_171"
Java(TM) SE Runtime Environment (build 1.8.0_171-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.171-b11, mixed mode)

这个故事告诉我们,虽然PrintAssembly开关打开了,但是系统不支持,缺少了hsdis-amd64.dylib文件。

这个hsdis是一个反汇编的工具,我们需要hsdis的支持才能在JDK8中使用Assembly。

我是mac系统,下面是在mac系统怎么安装hsdis:

hg clone http://hg.openjdk.java.net/jdk8u/jdk8u

cd jdk8u/hotspot/src/share/tools/hsdis/

wget http://ftp.heanet.ie/mirrors/ftp.gnu.org/gnu/binutils/binutils-2.30.tar.gz

tar -xzf binutils-2.30.tar.gz

make BINUTILS=binutils-2.30 ARCH=amd64

#java8
sudo cp build/macosx-amd64/hsdis-amd64.dylib /Library/Java/JavaVirtualMachines/jdk1.8.0_181.jdk/Contents/Home/jre/lib/server/

#java9 onwards
sudo cp build/macosx-amd64/hsdis-amd64.dylib /Library/Java/JavaVirtualMachines/jdk-9.0.4.jdk/Contents/Home/lib/server/

如果你是linux或者windows系统,请自行探索hsdis的安装方法。

按照步骤先把java8的hsdis-amd64.dylib安装好。

浅谈JVM和垃圾回收

然后再次运行测试命令:

完美,汇编语言出现了。

JDK14中的Assembly

然后我想到,如果把这个dylib文件拷贝到JDK14相应的目录下面,运行一次会怎么样呢?

大家注意,JDK9之后,使用了模块化,所以之前的目录结构发生了比较大的变化,大家参考上面我列出的地址。

再次运行测试代码:

大家看到,Assembly又出现了,真的是让我热内盈亏。

其实最开始的时候,我发现JDK14中Assembly没能正常显示的时候,我也有想过拷贝一个hsdis-amd64.dylib过来试试,但是一看还需要下载JDK的代码,重新编译,就打起了退堂鼓。

吃一堑,长一智,下次遇到问题千万不能走捷径。抄近路害死人呀!

在JMH中使用Assembly

Assembly主要是为了进行代码调优或者理解JVM的运行原理来使用的。

这里我们举一个在JMH中使用Assembly的例子:

@Warmup(iterations = 2, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 2, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(value = 1,
        jvmArgsPrepend = {
        "-XX:+UnlockDiagnosticVMOptions",
                "-XX:CompileCommand=print,com.flydean.PrintAssemblyUsage::testPrintAssembly"
}
)
@State(Scope.Benchmark)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class PrintAssemblyUsage {

    int x;
    @Benchmark
    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    public void testPrintAssembly() {
        for (int c = 0; c < 1000; c++) {
            synchronized (this) {
                x += 0xFF;
            }
        }
    }
    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(PrintAssemblyUsage.class.getSimpleName())
                .build();

        new Runner(opt).run();
    }
}

上面的例子中,我们使用了-XX:CompileCommand指定要打印的方法,而不是输出所有的Assembly,方便我们查看和分析结果。

总结

本文介绍了JDK8和JDK14中,怎么开启PrintAssembly。并举了一个在JMH中使用的例子。

那么有人会问了,在JMH中使用Assembly到底有什么意义呢?别急,我们在后面深入JVM的本质中,马上就要讲到,敬请期待。

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/jvm-jit-printassembly-2/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

小师妹学JVM之:JIT中的PrintAssembly续集
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

内存疯狂换页!CPU怒批操作系统

深入理解编译优化之循环展开和粗化锁

大多数人可能都不会使用socketTimeout,看了底层才知道一直都做错了

目录

简介

之前在讲JIT的时候,有提到在编译过程中的两种优化循环展开和粗化锁,今天我们和小师妹一起从Assembly的角度来验证一下这两种编译优化方法,快来看看吧。

循环展开和粗化锁

小师妹:F师兄,上次你讲到在JIT编译的过程中会进行一些编译上面的优化,其中就有循环展开和粗化锁。我对这两种优化方式很感兴趣,能不能展开讲解一下呢?

当然可以,我们先来回顾一下什么是循环展开。

更多精彩内容且看:

循环展开就是说,像下面的循环遍历的例子:

for (int i = 0; i < 1000; i++) {
                x += 0x51;
        }

因为每次循环都需要做跳转操作,所以为了提升效率,上面的代码其实可以被优化为下面的:

for (int i = 0; i < 250; i++) {
                x += 0x144; //0x51 * 4
        }

注意上面我们使用的是16进制数字,至于为什么要使用16进制呢?这是为了方便我们在后面的assembly代码中快速找到他们。

好了,我们再在 x += 0x51 的外面加一层synchronized锁,看一下synchronized锁会不会随着loop unrolling展开的同时被粗化。

for (int i = 0; i < 1000; i++) {
            synchronized (this) {
                x += 0x51;
            }
 }

万事具备,只欠我们的运行代码了,这里我们还是使用JMH来执行。

相关代码如下:

@Warmup(iterations = 10, time = 1, timeUnit = TimeUnit.SECONDS)
@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
@Fork(value = 1,
        jvmArgsPrepend = {
        "-XX:-UseBiasedLocking",
                "-XX:CompileCommand=print,com.flydean.LockOptimization::test"
}
        )
@State(Scope.Benchmark)
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
public class LockOptimization {

    int x;
    @Benchmark
    @CompilerControl(CompilerControl.Mode.DONT_INLINE)
    public void test() {
        for (int i = 0; i < 1000; i++) {
            synchronized (this) {
                x += 0x51;
            }
        }
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder()
                .include(LockOptimization.class.getSimpleName())
                .build();
        new Runner(opt).run();
    }
}

上面的代码中,我们取消了偏向锁的使用:-XX:-UseBiasedLocking。为啥要取消这个选项呢?因为如果在偏向锁的情况下,如果线程获得锁之后,在之后的执行过程中,如果没有其他的线程访问该锁,那么持有偏向锁的线程则不需要触发同步。

为了更好的理解synchronized的流程,这里我们将偏向锁禁用。

其他的都是我们之前讲过的JMH的常规操作。

接下来就是见证奇迹的时刻了。

分析Assembly日志

我们运行上面的程序,将会得到一系列的输出。因为本文并不是讲解Assembly语言的,所以本文只是大概的理解一下Assembly的使用,并不会详细的进行Assembly语言的介绍,如果有想深入了解Assembly的朋友,可以在文后留言。

分析Assembly的输出结果,我们可以看到结果分为C1-compiled nmethod和C2-compiled nmethod两部分。

先看C1-compiled nmethod:

第一行是monitorenter,表示进入锁的范围,后面还跟着对于的代码行数。

MyBatis执行流程的各阶段介绍

最后一行是monitorexit,表示退出锁的范围。

中间有个add $0x51,%eax操作,对于着我们的代码中的add操作。

可以看到C1—compiled nmethod中是没有进行Loop unrolling的。

我们再看看C2-compiled nmethod:

和C1很类似,不同的是add的值变成了0x144,说明进行了Loop unrolling,同时对应的锁范围也跟着进行了扩展。

最后看下运行结果:


Benchmark              Mode  Cnt     Score     Error  Units
LockOptimization.test  avgt    5  5601.819 ± 620.017  ns/op

得分还不错。

禁止Loop unrolling

接下来我们看下如果将Loop unrolling禁掉,会得到什么样的结果。

要禁止Loop unrolling,只需要设置-XX:LoopUnrollLimit=1即可。

我们再运行一下上面的程序:

可以看到C2-compiled nmethod中的数字变成了原本的0x51,说明并没有进行Loop unrolling。

再看看运行结果:

Benchmark              Mode  Cnt      Score      Error  Units
LockOptimization.test  avgt    5  20846.709 ± 3292.522  ns/op

可以看到运行时间基本是优化过后的4倍左右。说明Loop unrolling还是非常有用的。

总结

本文介绍了循环展开和粗化锁的实际例子,希望大家能够喜欢。

本文的例子https://github.com/ddean2009/learn-java-base-9-to-20

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/jvm-jit-loop-unrolling-lock-coarsening/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

深入理解编译优化之循环展开和粗化锁
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

Python 简明教程 — 21,Python 继承与多态

JIT的Profile神器JITWatch

7.跳表:各方面都非常优秀的动态数据结构

简介

老是使用命令行工具在现代化社会好像已经跟不上节奏了,尤其是在做JIT分析时,使用LogCompilation输出的日志实在是太大了,让人望而生畏。有没有什么更加简便的方法来分析JIT日志呢?快来和小师妹一起来学习JITWatch吧。

什么是JIT

小师妹,F师兄,JIT就是Just In Time compilers。能不能再总结一下JIT到底是做什么的呢?

当然没问题,JIT主要有两个作用,第一个作用大家应该已经知道了,就是在运行时将byte code编译成为机器码,提高程序的执行速度。

第二个作用就是在运行时对代码进行优化,同样的也对性能进行提升。

JIT中有两种编译器,C1代表的是Client Compiler,C2代表的是Server Compiler。

其中C1只是简单的编译,而C2在收集到更多信息之后,会进行更加深入的编译和优化。

常见的优化手段有:Loop unrolling, Inlining, Dead Code Elimination,Escape analysis, Intrinsics, Branch prediction等。

JDK8中会默认启动分层编译。你也可以使用-XX:+TieredCompilation来手动启动它。

JITWatch简介

小师妹:F师兄,上次你讲的LogCompilation和PrintCompilation输出结果还是太复杂了,尤其是LogCompilation,输出的结果有十几M,分析起来好难。有没有更简单一点的办法,让我的工作效率加倍呢?

这个必须有,有需求就有市场,有需求就有大神出场。今天给你介绍一个工具叫做JITWatch。

JITWatch是一个大神做的JIT日志的可视化分析工具。在使用它之前你可能觉得它有点强大,在使用后你就会觉得它真的是强大。

运行JITWatch

小师妹:F师兄,这么强大的工具,快快介绍我使用吧。

完全没有问题,不过JITWatch没有现成的打包好的可执行文件。没错,你需要到github上面下载源码。

下载完毕,可以执行:

mvn clean compile test exec:java

就可以开启JITWatch之旅了。

JITWatch详解

小师妹:F师兄,这么好用的工具为什么不打个包出来让大家直接用呢?还要下载源码这么麻烦。

其实吧,JITWatch为了大家方便使用,自带一个Sandbox功能,提供了一些可以直接在JITWatch中运行的代码,同时JITWatch可以实现源码的实时比对功能。所以需要大家下载源码。

闲话休提,我们开启JITWatch之旅吧。

入眼就是如此朴实无华的界面,让人感觉总有点…重剑无锋,大巧不工。高手做的UI就是这么的完美。

接下来我们需要运行一个程序,来实时感受一下JITWatch的魅力。

看到左边最上角的sandbox了吗?点开它可以看到下面的sandbox页面:

这一个页面会选择一个sadbox中的例子展示给你,大家注意下面的输出框的说明,它会显示你的Disassembler是否可用。如果想要安装disassembler,请参照我之前的文章。

如果你对这个例子不满意,或者你想使用自己的代码,那也完全没有问题。点击config。

这里你可以配置源代码的路径,可以选择VM的语言,还有各种VM的选项,下面的选项相信我在之前的文章中都已经介绍过了吧。

如果还有不懂的小伙伴,微信我,私聊我,1对1现场教学。

万事俱备,只欠东风,开始吧,我可是要成为Java王的男人!

然后我们就进入了TirView界面,这里我们可看到主界面分成了三部分,源代码,ByteCode和Assembly。

CentOS 7 Docker安装部署Go Web

小师妹:真是热泪盈眶啊,终于不需要自己去添加那些XX参数了。面向界面编程,真好。

上面还有几个按钮,这里简单介绍一下他们的功能,具体的界面这里就不截图了,因为实在是太多了….

Chain会展示调用链。

Journal就是之前使用LogCompilation产生的xml日志。

LNT,全称是line number table。—目前我还不知道这个是做什么用的,有知道的朋友,请给我留言。

然后就是Inlined into功能了,这个功能要详细讲一下,因为会影响到程序的执行效率。

还记得之前举的inline的例子吗?

int a = 1;
int b = 2;
int result = add(a, b);
...
public int add(int x, int y) { return x + y; }
int result = a + b; //内联替换

上面的add方法可以简单的被替换成为内联表达式。

JITWatch可以显示方法是否被inlined,并且显示出inlined的原因。

点击BCI可以显示关联的inlined的代码。大家自行体会。

现在再让我们回到可爱又有风格的主页面:

左边是源代码,包含了JDK自己的代码,如果你想详细的分析JDK自己代码的优化,那么这是一个非常好的工具。

右边显示的是被JIT编译的类和方法,并且展示了编译级别和编译的时间。

右上角又有一排按钮,Config是用来配置运行的代码。

TimeLine是以图形的形式展示JIT编译的时间轴。

Histo是直方图展示的一些编译信息。

TopList里面是编译中产生的一些对象的或者数据的排序。

Cache是free code cache空间。

NMethod是native方法。

Threads是JIT编译的线程。

TriView就是我们最开始展示的面板。

最后我们重点讲一下Suggestion:

Suggestion是对代码的一些优化建议。

从上图我们可以看到在调用String的hashMap方法时候无法inlined,因为被调用的方法太大了,超出了最大inlining size。

总结

所以,我们通过JITWatch可以学到什么呢?最最重要的是我们可以通过JITWatch来分析JIT的运行原理和本质。然后inlined的方法不要太大了,否则影响执行效率。

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/jvm-jit-jitwatch/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

JIT的Profile神器JITWatch
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

干!垃圾微软!发布我的Netcore跨平台UI框架 CPF

区块链系列教程之:比特币的问题

逻辑式编程语言极简实现(使用C#) – 4. 代码实现(完结)

目录

简介

比特币网络是中本聪作为一个实验性的网络提出来并运行的。没想到的是这一个实验性质的网络,居然成了现在虚拟货币世界的龙头老大。这个结局估计是中本聪本人都没有想到过的。

既然是一个实验性的网络,那么比特币网络中又隐藏着哪些痛点呢?快来看看吧。

攻击比特币网络

比特币网络是基于P2P架构的。在整个比特币网络中可能有成千上万的节点。

那么问题来了,这么多节点的网络,还会受到攻击吗?会受到什么类型的攻击呢?

下面讲三种攻击方式方式:

  1. 共识攻击(51%攻击): 如果一个人的挖矿算力,超过了全网算力的51%,就可以随意决定虚拟货币网络区块的内容,比如撤销交易或者制造虚拟交易等等,这意味着,整个虚拟货币的网络就此崩溃,所有虚拟货币的资产将掌握在这个持有51%算力的人手里。

  2. 自私挖矿攻击: 所谓自私挖矿,是指当一个”自私的矿池”挖到新的区块,在必须提交到网络节点之前,他们一直私下保存。该理论的依据是”自私的矿池 “保持了区块的私密性,让其余的网络算力浪费资源去挖掘,这样”自私的矿池”在挖下一个区块的时候就取得先机。

    “自私的矿池”还必须监视其它矿池,预测他们什么时候发现新的区块。当”诚实的矿池”广播发现一个新块的时候,”自私的矿池”还必须发动一个Sybil Attack(女巫攻击)以抢先让他们偷挖的区块得到网络的承认。区块头当然有时间戳,”自私的矿池”还必须有足够的Sybil节点来报告是”自私的矿池”先发现区块,这样网络会接受报告并奖励”自私的矿池”。

  3. 服务拒绝攻击: 大量发送小额交易,拥塞网络。我们要知道比特币网络的处理能力是非常非常弱的。每10分钟出一个块,一个块的大小是1M(当然,现在搞了个隔离见证好像容量提高了),块的大小有限,最终导致块中的交易是有限的。从而就限制了比特币网络的交易处理速度。

    如果这个时候网络接收到大量的小额交易,那么那些真正的大额交易就会被阻塞。

空块问题

空块的意思就是块中不包含任何交易。

那么空块是怎么产生的呢?假如我们有两个A,B矿池。

A矿池产生块后,把新块传遍全网是需要时间的。

B矿池收到A矿池新块的基本数据后,为充分利用算力,不等新块里的交易数据传完,就开始算下一个块了。

在传输交易数据的期间,B矿池有一定概率算出下一个块,这时候B矿池不知道哪些未确认交易已经被A矿池打包进前一个块,为避免打包了同一个交易,导致交易冲突,块被拒,B矿池就不会打包任何交易。

这就是空块的来历。

如果大家去查看比特币区块链的历史,可以发现(从区块364188到345469)一共18720个区块,其中只有1个交易(即coinbase交易)的有422个。

扩容问题

  • 清算系统

比特币区块链是全球的、分布式的、有限容量的、代价昂贵的系统。每一笔交易的价值含量是不一样的,当块容量不够用时,我们应该保障高价值的交易进块。高价值的交易有意愿有能力支付足够高的网络手续费,从而获得足够高的优先级进块。

随着比特币的繁荣,交易数量会越来越大,有限的块容量会使得低价值的交易(例如发送1分钱)永远无法进块,因为低价值的交易不可能支付高网络手续费。

进而网络退化为清算系统,低价值含量交易被赶出,这些交易由第三方记账系统进行代替完成。

在闪电网络出现之前,第三方记账系统主要是链外钱包提供商。用户信任某第三方钱包平台,把比特币存入其中,同一平台用户之间转账仅带来账户余额变更,并不会产生比特币交易。

  • 现金系统

现金系统意味着所有交易均应该进入区块,那么当块容量不够用时,则应该及时提高块体积限制,对系统进行扩容。短时间可能发生交易入块堵塞,但长期来看所有交易应该均可以入块。人人都享有比特币系统带来的巨大便利和优势。

为了解决区块链容量的问题,比特币在2017年8月24日引入了隔离见证。

  • 什么是隔离见证呢?

再来回顾一下上图的比特币中区块链中交易的构造。

每个交易的的input中都包含了一个ScriptSig,这个ScriptSig主要是用来做交易验证的,只对需要验证交易的矿工来说是有意义,对于普通用户来说这个ScriptSig是完全不需要的。

而隔离见证就是把这个ScriptSig剔除到了交易之外。从而扩大了可容纳的交易数量。

同时把ScriptSig剔除到了交易之外还有一个好处就是避免了交易延展性攻击(Transaction Malleability)。

  • 什么是延展性攻击呢?

延展性的意思是一个东西变形了,但其本质是不变的。对于交易来说,ScriptSig中包含的签名,其实是可以变化的。从而导致整个交易的变化,最后导致Transaction ID的变化。

因为Transaction ID是对整个交易做的一个Hash。

三十张图助你看清红黑树的前世今生

为什么签名是可以变化的呢?

因为对某一种签名算法来说,可能有好几种签名方式,从而多种签名方式都是正确有效的签名。但是最终会导致交易id的变化。

假设有这样一种情况。 小明在火币网发起了一笔提现交易。当这笔交易被广播到网络中,并且还没有被打包到区块中的时候。

小明监听到了这个交易,并对这个交易的签名做了微调,从而生成了一笔新的交易,发送到比特币网络中。

最终比特币网络接收了小明修改过的交易。

但是,这个时候小明可以向火币网投诉没有收到交易。火币网的客服会根据之前的交易id去查询这笔记录,当然是查不到的。最终火币网会赔偿小明一笔费用。于是,小明就攻击成功了。

区块链的膨胀问题

比特币的区块链大小是一直在增加的,其实不光是比特币,所有的区块链网络都会存在这个问题,因为每个区块链的节点都需要保存所有的链上信息。

我们看下区块链的大小,2020年,一个全节点的大小就会超过250G!

对立的社区

对于比特币而言,挖矿本身就是一种投票,原本的构想就是以CPU为单位用算力进行投票来确保系统的安全。但是随着“聪明”的技术人员们将CPU换成GPU,然后到FPGA,再到ASIC矿机,这条路已经和原来的初衷渐行渐远。

任何一个在比特币社区的人都会发现,持有比特币的人和挖矿的人成为完全不同的两个人群。比特币的矿工群体仿佛已经和社区完全割裂开来,许多矿工可能完全不了解比特币的生态,他们甚至不关心比特币的未来。

所以每年都可以看到一些奇怪的景象,持有比特币的社区不得不通过谴责和呼吁,要求某些矿池把算力降下来,以免严重影响比特币的发展。

而这些矿池也会表示自己是基于道德和觉悟来降低自己的份额。任何一个持有比特币的人,难道不对这种景象感到怪异么,比特币的命运竟然是掌握在并不一定关心比特币命运的人手上。

这似乎有点类似于,一个公司的命运并不是那些持有公司股份的股东来决定的,而是那些有可能根本不拥有股份,而只要有钱的人来决定的,也就是金融世界中的那些“门口的野蛮人”。那些持有比特币的人完全无法对比特币的未来做出自己的决定。我们仿佛从中本聪设定的一CPU一票的文明世界,一下子沦为纯粹是靠蛮力,看谁力气更大的原始社会。

失效的进化机制

比特币在发展初期主要是依靠以中本聪为核心的技术团队制定相关技术标准和研发比特币钱包。但是随着中本聪退出比特币界,这方面的任务就逐渐转移到比特币基金会。

比特币基金会是一个负责协调比特币发展的非营利机构。他们除了负责开发比特币钱包之外,还参与推广比特币理念和应用、教育市场以及和政府沟通等事项。由于基金会本身是非营利机构,只能依靠捐款来运作。但是比特币世界上大量的资金都投入到矿机中,而开发者很难从比特币发展中获利。

开发者往往面临一个两难的困境,由于比特币已经在全世界获得一定程度的认可,它的客户端被全球几百万人在使用,但是它的早期核心开发者已经不知所踪,让后续的开发者不敢改动核心代码,只能在外围做一些修补。因为一旦修改核心代码,任何的小问题都可能引起全球比特币网络的瘫痪(这在比特币发展过程中已经出现过),而没有太多的开发者愿意承担这样的风险。但是如果能够改动成功并且稳定运作,开发者除了获得社区的掌声之外,并不能获得任何实际上的利益。

并且是否使用新版本客户端的决定权在比特币矿工的手上,所以任何对矿工不利的修改都不可能通过,即使比特币基金会也无能为力,所以也导致开发者没有足够的热情去修改。在这种情况下,比特币客户端在发展了多年之后还是停留在非常原始的状态,不仅不适合普通人使用,而且完全不像一个互联网时代的软件。中本聪原本设想的社区众多开发者不断修改系统,出现像Linux一样,通过社区合力来推动系统顺应时代发展的情况并没有出现。

解决问题

那么对于区块扩容的问题,其实现在已经有了两个比较好的解决办法。

第一个就是闪电网络:

闪电网络可以看做是一个临时记账系统,比如说A和B直接有很多的交易,那么他们可以先在区块链中构建一个通道。

后面所有的交易都在这个通道中进行(可以通过智能合约的形式),只有通道关闭的时候,两者的交易才会正式更新到比特币网络中。

这样就为A和B节约了不少的交易费用。

还有一个叫做侧链技术

侧链技术实际上是在比特币网络之外又构建了一个链。比特币网络只做清算使用。

当然,为了解决比特币的问题,第二代甚至是第三代区块链技术平台都出现了。感兴趣的朋友可以继续关注我后续的更新。

总结

本文介绍了区块链网络中的困境和一些解决办法,希望大家能够喜欢。

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/bitcoin-in-trouble/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

区块链系列教程之:比特币的问题
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

Spring Cloud Alibaba系列(六)sentinel的实际应用

小师妹学JVM之:cache line对代码性能的影响

微服务框架Demo.MicroServer运行手册

目录

简介

读万卷书不如行万里路,讲了这么多assembly和JVM的原理与优化,今天我们来点不一样的实战。探索一下怎么使用assembly来理解我们之前不能理解的问题。

一个奇怪的现象

小师妹:F师兄,之前你讲了那么多JVM中JIT在编译中的性能优化,讲真的,在工作中我们真的需要知道这些东西吗?知道这些东西对我们的工作有什么好处吗?

um…这个问题问得好,知道了JIT的编译原理和优化方向,我们的确可以在写代码的时候稍微注意一下,写出性能更加优秀的代码,但是这只是微观上了。

如果将代码上升到企业级应用,一个硬件的提升,一个缓存的加入或者一种架构的改变都可能比小小的代码优化要有用得多。

就像是,如果我们的项目遇到了性能问题,我们第一反应是去找架构上面有没有什么缺陷,有没有什么优化点,很少或者说基本上不会去深入到代码层面,看你的这个代码到底有没有可优化空间。

第一,只要代码的业务逻辑不差,运行起来速度也不会太慢。

第二,代码的优化带来的收益实在太小了,而工作量又非常庞大。

所以说,对于这种类似于鸡肋的优化,真的有必要存在吗?

其实这和我学习物理化学数学知识是一样的,你学了那么多知识,其实在日常生活中真的用不到。但是为什么要学习呢?

我觉得有两个原因,第一是让你对这个世界有更加本质的认识,知道这个世界是怎么运行的。第二是锻炼自己的思维习惯,学会解决问题的方法。

就想算法,现在写个程序真的需要用到算法吗?不见得,但是算法真的很重要,因为它可以影响你的思维习惯。

所以,了解JVM的原理,甚至是Assembly的使用,并不是要你用他们来让你的代码优化的如何好,而是让你知道,哦,原来代码是这样工作的。在未来的某一个,或许我就可能用到。

好了,言归正传。今天给小师妹介绍一个很奇怪的例子:

private static int[] array = new int[64 * 1024 * 1024];

    @Benchmark
    public void test1() {
        int length = array.length;
        for (int i = 0; i < length; i=i+1)
            array[i] ++;
    }
    @Benchmark
    public void test2() {
        int length = array.length;
        for (int i = 0; i < length; i=i+2)
            array[i] ++;
    }

小师妹,上面的例子,你觉得哪一个运行的更快呢?

小师妹:当然是第二个啦,第二个每次加2,遍历的次数更少,肯定执行得更快。

好,我们先持保留意见。

第二个例子,上面我们是分别+1和+2,如果后面再继续+3,+4,一直加到128,你觉得运行时间是怎么样的呢?

小师妹:肯定是线性减少的。

好,两个问题问完了,接下来让我们来揭晓答案吧。

两个问题的答案

我们再次使用JMH来测试我们的代码。代码很长,这里就不列出来了,有兴趣的朋友可以到本文下面的代码链接下载运行代码。

我们直接上运行结果:

Benchmark               Mode  Cnt   Score   Error  Units
CachelineUsage.test1    avgt    5  27.499 ± 4.538  ms/op
CachelineUsage.test2    avgt    5  31.062 ± 1.697  ms/op
CachelineUsage.test3    avgt    5  27.187 ± 1.530  ms/op
CachelineUsage.test4    avgt    5  25.719 ± 1.051  ms/op
CachelineUsage.test8    avgt    5  25.945 ± 1.053  ms/op
CachelineUsage.test16   avgt    5  28.804 ± 0.772  ms/op
CachelineUsage.test32   avgt    5  21.191 ± 6.582  ms/op
CachelineUsage.test64   avgt    5  13.554 ± 1.981  ms/op
CachelineUsage.test128  avgt    5   7.813 ± 0.302  ms/op

好吧,不够直观,我们用一个图表来表示:

从图表可以看出,步长在1到16之间的时候,执行速度都还相对比较平稳,在25左右,然后就随着步长的增长而下降。

【逼你学习】让自制力提升300%的时间管理方法、学习方法分享

CPU cache line

那么我们先回答第二个问题的答案,执行时间是先平稳再下降的。

为什么会在16步长之内很平稳呢?

CPU的处理速度是有限的,为了提升CPU的处理速度,现代CPU都有一个叫做CPU缓存的东西。

而这个CPU缓存又可以分为L1缓存,L2缓存甚至L3缓存。

其中L1缓存是每个CPU核单独享有的。在L1缓存中,又有一个叫做Cache line的东西。为了提升处理速度,CPU每次处理都是读取一个Cache line大小的数据。

怎么查看这个Cache line的大小呢?

在mac上,我们可以执行:sysctl machdep.cpu

从图中我们可以得到,机子的CPU cache line是64byte,而cpu的一级缓存大小是256byte。

好了,现在回到为什么1-16步长执行速度差不多的问题。

我们知道一个int占用4bytes,那么16个int刚好占用64bytes。所以我们可以粗略的认为,1-16步长,每次CPU取出来的数据是一样的,都是一个cache line。所以,他们的执行速度其实是差不多的。

inc 和 add

小师妹:F师兄,上面的解释虽然有点完美了,但是好像还有一个漏洞。既然1-16使用的是同一个cache line,那么他们的执行时间,应该是逐步下降才对,为什么2比1执行时间还要长呢?

这真的是一个好问题,光看代码和cache line好像都解释不了,那么我们就从Assembly的角度再来看看。

还是使用JMH,打开PrintAssembly选项,我们看看输出结果。

先看下test1方法的输出:

再看下test2方法的输出:

两个有什么区别呢?

基本上的结构都是一样的,只不过test1使用的是inc,而test2方法使用的add。

本人对汇编语言不太熟,不过我猜两者执行时间的差异在于inc和add的差异,add可能会执行慢一点,因为它多了一个额外的参数。

总结

Assembly虽然没太大用处,但是在解释某些神秘现象的时候,还是挺好用的。

本文的例子https://github.com/ddean2009/learn-java-base-9-to-20

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/jvm-jit-cacheline/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

小师妹学JVM之:cache line对代码性能的影响
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

通过手写服务器的方式,立体学习Http

小师妹学JVM之:JVM中的Safepoints

漫画:Integer 竟然有 6 种比较方式?

目录

简介

java程序员都听说过GC,大家也都知道GC的目的是扫描堆空间,然后将那些标记为删除的对象从堆空间释放,以提升可用的堆空间。今天我们会来探讨一下隐藏在GC背后的一个小秘密Safepoints。

GC的垃圾回收器

小师妹:F师兄,GC的垃圾回收器的种类为什么会有这么多呀?使用起来不是很麻烦。并且我听说CMS在JDK9zhong已经被废弃了。

小师妹,这么多垃圾回收器实际是在JVM的发展过程中建立起来的,在之前的文章中,我们讲到了目前的GC回收器有这样几种。

  1. 基于分代技术的回收器

Concurrent mark sweep (CMS) ,CMS是mark and swap的升级版本,它使用多个线程来对heap区域进行扫描,从而提升效率。

由于CMS的参数复杂性和性能问题,CMS已经在JDK9中被废弃了。

Serial garbage collection,使用单一的线程来进行垃圾回收操作,其好处就是不需要和其他的线程进行交互。如果你是单核的CPU,那么最好就是选择Serial garbage collection,因为你不能充分利用多核的好处。同样的它也常常用在比较小型的项目中。

Parallel garbage collection,如果你是多核处理器,那么Parallel GC可能是你的选择。

Parallel GC是JDK8中的默认GC。而在JDK9之后, G1是默认的GC。

G1 garbage collection,G1=Garbage First,它是为替换CMS而生的,最早出现在java7中。

G1将heap区域划分成为多个更小的区域,每个小区域都被标记成为young generation 或者old generation。从而运行GC在更小的范围里运行,而不是影响整个heap区域。

  1. 非基于分代技术的回收器

Z Garbage Collection,ZGC是一个可扩展的,低延迟的GC。ZGC是并发的,而且不需要停止正在运行的线程。

ZGC是在JDK11中引入的。

当然还有正在研发中的其他GC。

分代回收器中的问题

小师妹:F师兄,分代回收器不好吗?为什么还有新的ZGC等基于非分代技术的回收器?

分代垃圾回收器中有一个非常常见的现象就是”Stop The World”。什么是Stop the world呢?

就是说在GC的时候,为了进行垃圾回收,需要所有的线程都要暂停执行。所有的线程都暂停执行。

当然G1虽然是基于分代技术,但是G1实际上是不会”Stop The World”的。

推荐一款Python开源库,技术人必备的造数据神器!

JVM定义了一些Root对象,从这些对象开始,找出他们引用的对象,组成一个对象图。所有在这个图里面的对象都是有效的对象,反之不在对象图中的对象就应该被回收。有效的对象将会被Mark为alive。

这些Root对象包括:正在执行的方法中的本地对象和输入参数。活动的线程,加载类中的static字段和JNI引用。

safepoints

为了实现STW的功能,JVM需要提供一个机制,让所有的线程可以在某一个时刻同时停下来。这个停下来的时刻就叫做safepoints。

注意,这些停下来的线程不包括运行native code的线程。因为这些线程是不属于JVM管理的。

JVM中的代码执行其实有两种方式,一种是JIT编译成为机器码,一种是解释执行。

在JIT中,直接将检查代码编译进入了机器码中。通过设置相应的标记位,从而在线程运行的过程中执行暂停的指令。

还是举一个上篇文章中我们提到的JMH的例子:

@Benchmark
    public void test1() {
        int length = array.length;
        for (int i = 0; i < length; i=i+1)
            array[i] ++;
    }

我们看一下它的assembly code:

可以看到其中有个test的指令,这个test指令就是生成的safe points。

通过设置标志位,就可以在线程运行时执行暂停操作。

如果是解释执行的话,JVM保存了两个字节码的调度table,当需要safepoint的时候,JVM就进行table的切换,从而开启safepoint。

safepoint一般用在什么地方

一般情况下,GC,JIT的反代码优化,刷新code cache,类重定义 ,偏向锁撤销和其他的一些debug操作。

我们可以通过使用-XX:+PrintGCApplicationStoppedTime来print safepints的暂停时间。

-XX:+PrintSafepointStatistics –XX:PrintSafepointStatisticsCount=1这两个参数可以强制JVM打印safepoint的一些统计信息。

总结

Safepoint是垃圾回收中一个非常重要的概念,希望大家能够有所了解。

本文作者:flydean程序那些事

本文链接:http://www.flydean.com/jvm-jit-safepoints/

本文来源:flydean的博客

欢迎关注我的公众号:程序那些事,更多精彩等着您!

小师妹学JVM之:JVM中的Safepoints
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

零拷贝(Zero-copy) 浅析及其应用

小师妹学JVM之:Dirty cards和PLAB

毕业三年了,我开始明白为什么说三年是一个坎

目录

简介

分代垃圾回收器在进行minor GC的时候会发生什么操作呢?有没有什么提高效率的手段呢?今天我们和小师妹一起来了解一下垃圾回收中的Dirty cards和PLAB

分代收集器中的空间划分

小师妹:F师兄,能再讲讲分代垃圾收集器中的空间划分吗?

分代垃圾回收器中的Eden,Old和Survivor space几个大家应该都很熟悉的分代技术。

Young Gen被划分为1个Eden Space和2个Suvivor Space。当对象刚刚被创建的时候,是放在Eden space。

当Eden space满的时候,就会触发minor GC。会扫描Eden Space和一个Suvivor Space。如果在垃圾回收的时候发现Eden Space中的对象仍然有效,则会将其复制到另外一个Suvivor Space。

就这样不断的扫描,最后经过多次扫描发现仍然有效的对象会被放入Old Gen表示其生命周期比较长,可以减少垃圾回收时间。

Write barrier和Dirty cards

小师妹:F师兄,minor GC的时候,要将对象从Eden复制到Suvivor Space,从Suvivor Space中复制到Old space。GC是怎么知道哪些对象是要被回收,哪些是不用被回收的呢?

小师妹,GC这里用到了一项叫做Dirty cards的技术。

一般来说,新的对象是分配在Eden空间的。但是也有些对象是直接分配在Old space。

我们知道,GC的扫描是从一些根对象开始的,这些Root对象包括:正在执行的方法中的本地对象和输入参数。活动的线程,加载类中的static字段和JNI引用。

而这些根对象,一般都是存储在old space中的。

通常来说old space的空间都会比较大。每次要要找到Eden和suvivor Space中哪些对象不再被引用,需要扫描整个old space肯定是不可取的。

所以JVM在这里引入了Write barrier的技术。HotSpot中有两种Write barrier,一种就是今天我们要讲的Dirty cards,另外一种就是snapshot-at-the-beginning (SATB)。 SATB通常用在G1垃圾回收器中,这里我们先不做深入的讨论。

浏览器安全

我们看下上图中的Dirty cards的使用。

Dirty cards说起来很简单,就是每当有程序对引用进行修改的时候,我们都会在一个Dirty cards的空间记录一下被修改的memory page。

这样在minor GC的时候,当引用的对象被修改了之后,我们会同步修改对应的Dirty cards。这样每次扫描old space的时候,只需要选择那些标记为Dirty cards的对象就可以了,避免了全局扫描。

PLAB

小师妹,F师兄,你讲的好像很有道理的样子,上次你讲到我们在Eden空间分配对象的,为了提升分配的效率,使用了TLAB的计算。那么在对象从Eden空间提升到Suvivor Space和old Space的时候有没有同样的技术呢?

当然有的,这个技术就叫做PLAB( promotion local allocation buffer)。每一个线程在survival space和old space中都一个PLAB。在提升的时候,可以避免多线程的竞争,从而提升效率。

我们可以使用-XX:+AlwaysTenure 将对象直接从Eden space提升到old space。

我们可以使用-XX:+PrintOldPLAB来输出OldPLAB的信息。

old space分配对象

小师妹:F师兄,刚刚你讲到新分配的对象可以直接在Old space,一般什么对象可以这样分配呢?

这个很好理解,如果你分配对象大小超过了Eden space的大小,是不是就只有old space可以分配对象了?

小师妹:对的,但是一般来说也不会使用这么大的对象吧。

对的,我们可以通过设置-XX:PretenureSizeThreshold=n 来指定对象的大小,如果对象大小大于n,那么就直接在old space分配。

注意,如果这个对象的大小比TLPB要小,那么会首先在TLPB中分配。所以使用的时候要注意限制TLPB的大小。

总结

GC的运行是一个比较复杂的过程,大家可以细细体会。本文如果有什么谬误之处,欢迎微信我指正。谢谢大家。

本文已收录于 http://www.flydean.com/jvm-dirty-card-plab/

最通俗的解读,最深刻的干货,最简洁的教程,众多你不知道的小技巧等你来发现!

欢迎关注我的公众号:「程序那些事」,懂技术,更懂你!

小师妹学JVM之:Dirty cards和PLAB
免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如此页面有侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。

通过源码学习@functools.lru_cache