编程语言
首页 > 编程语言> > 高性能编程论述

高性能编程论述

作者:互联网

高性能编程

前言

首先说一下我为什么要写这篇博客。因为面试有提到这个,我当时直接说不懂(一方面当时心态很差,另一方面面试官的询问方式令我很反感。所以直接refuse了。小伙伴们千万别学我)。

所以,打算谈一谈我对Java高性能编程方面的认识与总结。

首先,高性能编程不涉及架构层次。所以打算通过这篇文章,来了解架构提升系统性能的小伙伴要失望了。我将Java高性能编程主要分为编码与网络两个部分(说白了,只关注编码,不提其它)。

其次,我们需要了解何为高性能。性能往往与系统的吞吐量,响应时间,并发量等息息相关。只有了解到这点,我们才可以对症下药。

网络部分:BIO,NIO,Netty等,这部分在之前的《从BIO到Netty的演变》有所提及,这里不再赘述。

而编码部分,也是最多人关注的部分。我将它按层次分为:

并发容器被归类到多线程中,而Fork/Join框架被归类到特定机制(当然,也可以归类到算法,多线程等。取决于看待它的角度)。

由于这其中每个分支,拆分出来都是很大的一块内容。所以这篇文章的目标只是给个方向而已,不会写得非常深入。

一,数据结构

这里的数据结构指的是,类中属性的数据类型,可以是Java自带的数据类型,也可以是自定义的数据类型。

那么数据结构是如何影响性能的呢?这可以从我之前提到的高性能编码的六个层次去分析。这里不在展开,否则就是无限地递归分析了。

说得再多,不如举一些例子(好吧,其实这边的总结,我感觉不够好。划分的维度,我自己不满意而已)。

1.Integer与int:

比如Integer与int,在大量数据处理时,内部结构最好采用int类型,从而避免基本数据类型装箱拆箱带来的性能损耗。而这一点在《阿里开发手册》中也有提及,所以在不知道怎么做时,跟着规范走,也不失为一种选择。

PS:记得当时,我回答面试官高性能编程问题时,就是从《阿里开发手册》规范谈起。然后面试官打断说,我不是问你规范,我就问你怎么高性能编程。当时心态本来就不好,我想引经据典,都不让我说。所以我直接一句,我不懂。不过不推荐大家学我,该回答还是要回答滴。

2.String,StringBuffer,StringBuilder:

比如String,StringBuffer,StringBuilder(这三个应该鼎鼎有名了)。

其中最常用的时String,其底层实现是一种常量字符串(也就是不可变字符串)。其底层就是final修饰的,所谓的String更新,其实是返回了一个新的字符串。由于是常量,所以也就没有什么线程安全问题了,故线程安全。

其次就是我目前用得最多的,就是StringBuiilder,其内部是维持一个可变长度的char[]。字符串更新,也是采用底层的native方法,所以效率非常高,是三个字符串类型中效率最高的。但没有做线程安全处理,所以线程不安全。

最后就是在一些高并发框架,中间件底层中常看到的StringBuffer,其内部基本与StringBuilder类似。不过不同的是其中多数方法采用了Synchronized修饰,作为线程安全的处理,所以线程安全。

所以,就有了以下的使用场景:

如果表示上面的记不住。那就这样记:微量使用,用String;单线程最快,是StringBuilder;多线程安全,是StringBuffer。

其实数据结构,还有NIO的ByteBuffer,Netty的ByteBuf等,可以聊。不过这里不再赘述。

二,语言特性:

这里的语言特点,指的是Java语言的一些高级特性(我也不知道算不算高级,不过确实有不少人不清楚,所以就这样写吧)。

那么语言特性是如何影响性能的呢?其实,其中涉及到语言的底层实现(这个实现,其实也可以按照六个层次分析)。

继续举例子。

1.for循环JIT优化:

这个部分,涉及JVM的JIT编译。简单说一下,JIT是一种即时编译手段。Java代码一般采用解释,但在遇到重复执行代码块等,会进行编译,从而提升速度。其中又涉及到无数人深恶痛绝的三大重排序(编译器,指令,内存)之一-JIT重排序。

扯远了,收回来。那么for循环中的循环体,当然属于重复执行的代码块喽。所以for循环会被JIT优化,提升运行速度。所以在有些场景下,别觉得for循环很low,觉得迭代器(了解迭代器模式,应该知道迭代器模式本身,不存在循环体这样的代码块),Stream看着高级。在所有场景下,for循环效率高于迭代器,在多数场景下,for循环效率高于Stream。

当然,由于性能并不是系统的唯一质量属性,所以站在扩展性等方面,我们也需要对iterator等正确看待。没有最好的技术,只有更合适的技术。

2.Stream:

Stream作为Java8新引入的特性,不少人对它了解甚少。看到别人处理集合的Stream代码,简直看得口水都下来了,想着自己什么时候才能写出这样优雅的代码。

遥想当初,我也是看着大佬处理订单集合的代码,流口水,果断去学习这个,然后。。。扯远了,拉回来。

前面已经提到了,在多数场景下for循环的效率高于Stream。只不过for采用的是外部迭代,而Stream采用的是内部迭代。但是Stream和迭代器一样,没有类似循环体的代码块,所以没有这方面的JIT优化。所以在正常应用场景下,两者存在一定的差距(数据量大了后,两者的差距也在10%之内)。

但是,Stream有一个方法-parallel()。这个方法就厉害了,它是一个并行流。说白了,就是多线程处理当前流,通过多线程方法,将当前流拆分为多个流,来并行处理。

是不是感觉追根揭底,还是能归类到之前提到的六个层次中。

既然并行流效率这么高,为什么还用for循环呢?

因为并行流有着诸多限制。首先它内部是采用了多线程的处理手段,所以多线程的约束它都有(如CPU核心数带来的限制等)。其次它对流的处理必须是可以并行的,如过滤,转变,提交等。但是如排序,findFirst这样需要整个流的操作,就无法实现(或者说无法获得正确结果),或者实现效率极低。

所以,在一些可以并行操作的情况下,并且数据量较大,那么推荐使用并行流处理。优雅而高效。

3.迭代器:

这里提一下迭代器,否则大家就抛弃这个了。

迭代器的好处:自定义迭代逻辑,无返回函数的集合处理等。

其实迭代器,我用得并不多,一方面是一开始看到有前辈这样写,所以学习了一下这种写法。不过后来大多用for,以及Stream了。另一方面,就是面试问到如何通过无返回方法,修改集合元素。我当时只想到了Java方法参数不是引用传递这个点,解决还整没想到。面试官后来告诉我,可以通过迭代器实现。囧

三,算法:

算法这部分内容就海了去了。而且以我现在的算法积累,感觉并不能很好地解释这个问题。所以简单举些例子吧,以后有机会,再深入阐述算法(等我深入学习后,计划在明后年深入)。

比如排序算法,这也算是算法实现比较多的。感兴趣的,可以看我在博客园C语言算法部分总结的八大排序算法。

1.红黑树:

面试集合必问的HashMap与ConcurrentHashMap按不同版本(Java8及Java8以前)可以分为四个。其中不同版本之间最大的区别就是Java8之后,两者底层增加了红黑树(再单个链表达到阈值后,就会树化)。

那为什么红黑树可以提高性能呢?

在原本的HashMap(以HashMap为代表)中,最初数据操作的时间复杂度平均为O(logn)。但是存在数据集中于数组特定位置的情况(HashMap底层数据结构是数组+链表,链表作为数组的元素),最糟糕情况就是数据集中在数组一个下标下,即所有元素在同一个链表。那么链表的数据操作的时间复杂度就变成了O(n)。

为了避免这一情况,新版本的HashMap增加了红黑树。在单个链表的数据量达到阈值后,则会将链表转为红黑树,从而确保在数据多的时候(即n较大时),时间复杂度依旧为O(logn)。

时间复杂度降低了,说明CPU占用时间降低了,即性能提升了。

2.分治算法:

分治算法作为一种及其重要的算法思想,可以说程序中很多地方都体现了这点。甚至有人总结分布式系统的高并发就是限流(非侠义的限流,保护下游服务)与分流(提高吞吐量),而分流也是分治思想的一种体现。

那为什么分治算法可以提高性能呢?其实分治算法也是一种空间换时间的体现。更深入的阐述,其实就是均衡。

这里简单阐述一下我对均衡的认识。早在架构相关的博客中,我就提到,架构设计就是一个权衡的过程。提高性能,可能就需要降低安全性。提高系统扩展性,可能就会带来系统复杂度的提升。这点可用于各个层次,包括设计模式也是这样的。以后有机会深入阐述这种思想。

举一个分治算法的体现例子。如Fork/Join框架,通过对现有任务的拆分,分开进行计算,最终汇总。其实本质所需要的算力并没有改变,但是可以充分利用多线程,或者CPU多核的特性(其实还涉及CPU资源的竞争,不再深入)。

再举一个分治算法的体现例子,正好也是我在阿里面试时遇到的一个问题,如何实现淘宝双十一交易额的实时统计(延迟不得高于1s)。我的实现思路,就是一方面利用Redis内存数据库的高速特性(单台Redis实例正常每秒都可以有几十万的读写)。另一方面就是利用分治算法,将统计任务进行拆分。

这里说一下我的思路吧。首先排除大数据,因为我不熟悉大数据,而且我面试的也不是大数据,最重要的是大数据底层也需要实现(不能面试时,就扔个名词)。其次通过redis来提供一个分布式系统的存储(分布式系统的存储无非缓存,数据库,文件系统,消息队列算半个吧)。这个时候,需要思考的是,虽然redsi可以提供足够的读写,但是在数据处理时,程序为了确保数据不被别的程序修改,一定需要加分布式锁。那么时间消耗就体现在了这里。参照ConcurrentHash分段锁,及其体现的分治算法。可以将交易额按照业务,地域,或者单纯的数字拆分为多个字段(如1000g个),然后分别计算,最后通过一个服务,按照交易额刷新时间进行统计(这里统计还可以使用fork/join框架)。当然,这并不是一个完整的程序,其中还有许多的细节,如动态管理等。但是这样的思路是可行的。

对算法感兴趣的,可以看看相关算法书籍,刷刷leetcode等。

四,设计模式

设计模式部分,就是利用设计模式的特点,来达成提高程序性能的目的。

其实设计模式本身是面向对象设计原则(单一职责原则,里氏替换原则,开闭原则,依赖倒置原则,接口隔离原则,组合复用原则,迪米特原则)的落实,而这七大原则并没有性能方面的要求。所以大部分设计模式并没有性能提升的能力。但是部分设计模式由于其特定机制,以及语言特性,有了性能方面的提升。

1.单例模式

单例模式,由于其构造方法私有,所以无法通过构造器新建。这点透出其本质,单例模式保证了一个类只有一个实例,该实例只需要创建一次,并不会销毁。

这里简单说一下,由于是单例,所以线程安全。另外Spring的bean默认是单例的。某些情况下,可能需要通过注解,实现多例,此时就需要注意线程安全问题了。

由于单例的延迟加载,以及实例只创建一次,不会销毁的特性。在某些对象重复使用的情况下,会带来性能的提升。甚至在某些情况下,可能需要建立容器单例(一个容器,管理多个单例,如Spring)。

2.原型模式

原型模式,就是指定目标对象类型,通过拷贝来生成对象,而不需要调用构造器。而通过对象拷贝生成对象的效率远高于构造器生成对象。

所以需要大量相同对象时,可以通过原型模式,来实现相同对象的高效生成。

但是,这里提醒一下,原型模式需要注意复杂对象的拷贝问题。复杂对象的拷贝容易产生问题,这其中设计浅拷贝与深拷贝问题。感兴趣的朋友,可以查阅相关资料。

3.享元模式

享元模式,通过减少对象数量,从而改善应用所需的对象结构。既然减少了对象的创建,那么也就减少了内存中对象数量,从而降低了系统内存占用与对象创建的资源消耗。

所以需要大量类似对象时,如缓存池等,可以采用享元模式,来提高系统性能。

享元模式,貌似在系统底层应用得比较多。

以上,通过三个设计模式,简单阐述了设计模式带来的编程性能。更多的应用,需要各位朋友自行探讨。

五,多线程

这个部分,应该是多数人在高性能编程时优先考虑到的点。也是诸多面试的重点,所以这里我就简单说一下。

多线程是如何提高编程性能的呢?这其中有多种原因。

这里还有一点,需要进行说明。那就是线程数量的增加,带来了局部程序的性能提升,但其实降低了系统整体性能。因为每个线程都有竞争CPU时间片的资格。在达到一定的总线数量后,某个程序的线程数增加,只是增加了其获得CPU时间片的时间。而整体CPU时间是固定的,也就是系统整体性能并没有带来提升,并且系统整体性能反而因为线程的上下文切换等原因,降低了性能。当然这个总线程数量的“一定”是不好把握的。并且在某些情况下,多个线程会带来一定的平滑效果。

为了更好的说明,下面举一些例子。

1.资源阻塞:

这个应该是一个比较好理解的例子。

正如之前提到的数据库的例子。单个服务所需总时间为1s,其中数据库资源访问花了0.9s,程序运行花费0.1s。如果是单线程,这个服务的吞吐量就只有1/s。那如果采用多个线程,并且线程数量设置为10,那么该服务的吞吐量就有10/s。甚至在数据库等条件允许的情况下,这个服务的吞吐量可以无限大,只要线程数量足够(当然实际是不可能的,总会有新的性能瓶颈出来的)。

这个应用,请大家牢牢记住,因为这是一个非常常用的应用。

2.CPU核心数

大家都知道,一个线程会竞争一个CPU。而如今很多服务器都是多核的。那么为了充分利用服务器的多核特性,面对计算密集型任务,我们往往将其线程数量设置为CPU核心数。

举个例子,八核服务器上有这么一个服务,需要进行挖矿计算(其采用POW算法,是非常消耗算力的)。如果单线程的话,那就是传说中的“一核有难,七核围观”(一个CPU核心疯狂工作,其余七个CPU核心基本空闲)。那么算力的产出就只有1。那么如果是多线程,并且设置线程数为8,那么服务器八个核心都会疯狂工作。算力的产出有8。如果采用多线程,并且线程数为9(大于8)。那么就是服务器八个核心疯狂工作,8个线程在执行,还有1个线程在疯狂插队。从而导致服务器八个CPU核心,是不是还得停下来,切换上下文,从而换一个线程执行。最终算力产出低于8。

这种情况下,一定要考虑上下文切换的资源消耗。另一方面,一定要清楚总体算力,算力有多少是真正应用到目标程序中,最终算力产出是多少。

3.平滑CPU计算

这个比较难以理解,也基本看不到人提及,实际应用价值也不大(一般用不到)。而且没有在实际应用中,真的应用,只能说从理论方面探寻。

之前提到的上下文切换,说白了就是CPU将数据从内存中读取到CPU中,再将之前线程的数据保存到内存中。

那么如果服务执行的数据量很大呢?

单线程情况下,一方面上下文切换时数据量较大(可以将上下文理解为程序快照),另一方面由于高速缓存无法承载如此大的数据量,就会频繁与内存发生数据交互(这涉及内存管理,这里不再赘述,详见软考-架构师系列博客)。

多线程情况下,一方面上下文切换时数据量较小(但是总体不变,甚至更大,但是合理的程序设计,有可能上下文切换占用内存更低),另一方面,避免了高速缓存无法承载过多数据的问题。

多线程提高性能的情况,多数可以归于上述三类(或者说前两类吧)。有不同看法,或者有无法归类上述类型的,欢迎提出,共同进步。

六,特定机制

特定机制,就类似于一些取巧的方法,大多是采用系统资源交换来实现(如空间换时间等)。

常见的有:

1.Fork/Join框架

这个框架已经在前面的算法部分提及,这里只是站在机制角度多说两句。

一方面,多数的机制,也都可以按照高性能六个层次来分,只不过成为了较为成熟的方案而已。另一方面,多数机制都是采用分治,资源交换等来实现的。

2.CopyOnWriteArry

这是JDK中的一个数组,用于针对读多写少的场景。

最早,解决数组数据的读写问题,我们都是单线程操作,除了效率低,没什么问题。

然后,为了提高性能,我们采用了多线程,而线程不安全的数组会给我们带来线程安全问题。

紧接着,为了解决线程安全问题,最早采用简单的独占锁来解决这个问题。

后来,人们发现读的操作并不会带来线程安全问题(因为没有数据修改,等同于操作常量)。所以人们采用读写锁来解决线程安全问题(读写锁,即同时只能一个写操作,但可以有多个读操作。这里可以复习一下锁降级概念)。

最后,人们给出了更好的解决方案-CopyOnWriteArry。同时有两个数组,一个进行读操作,一个进行写操作。但是就像JVM运行时数据区中的Survive区一样,在一个写操作完成后,写数组与数组就进行切换(这个切换,只需要修改数组的指向Reference即可)。这样就保证了最高效的读操作。这和数据库的读写分离有着异曲同工之妙(只不过,一般不直接进行切换而已)。

通过,双倍的内存空间消耗,换来了读操作的大幅提升,即程序性能提升。

3.Netty的零拷贝:

Netty的零拷贝机制,来源于Netty的ByteBuf。而ByteBuf有着诸多优点,这里不再赘述,感兴趣的可以等待我的Netty源码分析的博客。

这里只简单说一下其中的零拷贝机制。

Netty的零拷贝机制,体现在两点。第一个是多个实际数据的虚拟逻辑组合。另一个是避免数据在内存中的用户空间与内核空间之间的拷贝。

前者就是通过CompositeByteBuf,将多个ByteBuf合并为一个** 逻辑** 上的ByteBuf,避免了各个ByteBuf之间的拷贝。举个栗子,现有数组A与数组B,你需要两个数组的合并数组C。正常就是生成一个新的数组,将两者copy过来。而零拷贝,则是数组C中包含数组A和数组B的指向。

后者则涉及内存的用户空间与内核空间的知识,这里不再解释两者,感兴趣的可以查看我早期Windows内核编程的相关部分。而ByteBuf的零拷贝用到了Java的FileChannel.transferTo方法,直接将文件缓冲区的数据,直接发送到目标Channel(网卡接口Buffer)。

ByteBuf对直接内存的使用,算是一种支撑。但是其独立出来,我认为并不能体现零拷贝特性。

当然,零拷贝的应用还有很多,包括Kafka等,也有相关应用。

七,总结

最终,我想说的是,高性能,其实也和架构设计一样,伴随着均衡,即有得有失。只不过有些东西,在系统的目标中权重并不高,或者说并没有那么高的要求而已。我们要做的是找到性能的瓶颈,去处理它。

如果上述观点,有任何不当或不足的,可以直接私信或@我。愿与诸君共进步。

标签:性能,编程,算法,高性能,线程,拷贝,多线程,论述,CPU
来源: https://www.cnblogs.com/Tiancheng-Duan/p/12033447.html