软件构造实验五

1. 实验目标概述

本次实验通过对 Lab4 的代码进行静态和动态分析，发现代码中存在的不符 合代码规范的地方、具有潜在 bug 的地方、性能存在缺陷的地方（执行时间热点、 内存消耗大的语句、函数、类），进而使用第 4、7、8 章所学的知识对这些问题 加以改进，掌握代码持续优化的方法，让代码既“看起来很美”，又“运行起来 很美”。 具体训练的技术包括：

⚫ 静态代码分析（CheckStyle 和 SpotBugs）

⚫ 动态代码分析（Java 命令行工具 jstat、jmap、jcmd、VisualVM、JMC、 JConsole 等）

⚫ JVM 内存管理与垃圾回收（GC）的优化配置

⚫ 运行时内存导出(memory dump)及其分析（Java 命令行工具 jhat、MAT）

⚫ 运行时调用栈及其分析（Java 命令行工具 jstack）；

⚫ 高性能 I/O

⚫ 基于设计模式的代码调优

⚫ 代码重构

1. 实验环境配置

VisualVM安装较麻烦一些，首先进入官网下载eclipse相应插件，解压到根目录，在eclipse下help下面的安装新的软件，选择解压好的文件，一路默认即可。安装完成后要在配置： 在window的preferences中进行VisualVM的配置，需要配置它的启动器（jdk、bin目录下面的jvisualvm.exe）还有jdk目录（注意是jdk不是jre）点击apply，ok即可完成安装配置

MAT和CheckStyle直接在marketPlace搜索傻瓜式安装即可，（注意Checkstyle的C大写，s小写要不然搜不到。。。。。。）

SpotBugs在lab4已经安装

在这里给出你的GitHub Lab5仓库的URL地址（Lab5-学号）。

https://github.com/ComputerScienceHIT/Lab5-1170300527.git

1. 实验过程

请仔细对照实验手册，针对每一项任务，在下面各节中记录你的实验过程、阐述你的设计思路和问题求解思路，可辅之以示意图或关键源代码加以说明（但千万不要把你的源代码全部粘贴过来！）。

1. 1. Static Program Analysis
      1. 人工代码走查（walkthrough）

1.Switch和case,自动format时没有缩进,Google要求有缩进,手动调整

2.要求每个函数都有doc,构造方法等之前没有添加,此次添加

3.缩进要求两个,以前都是4个,更改java->Code Style->format中设置

4.Google中不能使用tab要使用空格,更改Text Editor设置,format设置

勾选上insert spaces tabs

选择space only,tab size设为2

1. 1. 1. 使用CheckStyle和SpotBugs进行静态代码分析
2. 类命名不符合规范,person改为Person,使用重构工具,首字母全部改为大写

1. 包命名全部小写,在lab3中要求的包名有些不符合规范未进行修改

1. Javadoc的第一句缺少一个结束时期。第一行加上”.”

1. 变量名,小写字母开头,小写字母要大于两个,rename重构
2. 方法名开头小写,不能连续两个大写字母,rename重构
3. *类在自己源文件中,新建class

1. 导入包按的字典顺序

1. 分开定义

1. 字符过多,换行

1. If的{},自动生成的equal也要改…………

1. 等等等
   1. Java I/O Optimization
      1. 多种I/O实现方式

实现了Reader/Writer ,Buffer/Channel, java.nio.file.Files三种I/O方式,

Reader/Writer使用的bufferreader和bufferwrite,较为简单,直接调用其中的read和write方法即可

Buffer/Channel读取文件时使用MappedByteBuffer RandomAccessFile的内存映射,读入速度较其他方法快了很多倍,但读入的并非string,将其转化为string后就慢了很多,基本和bufferread差不多,写文件采用的bytebuffer

java.nio.file.Files方法也较为简单,直接调用readAllline和write即可将数据直接全部写入

使用strategy设计模式,创建接口readandwrite,包含read和write接口,

创建三个类以三种I/O策略实现接口,ReadWrite,Channel,NioFile分别实现Reader/Writer ,Buffer/Channel, java.nio.file.Files,这里只进行读取与写入,未进行处理,处理仍然交给三个系统分别处理,否则三个系统的匹配,写入格式都不同,将需要创建九个类.

在三个系统中创建策略对象,这样可以通过传入的策略以不同的I/O处理文件

从重构到重写啊….读入之后内存直接炸掉,读写文本简单,处理就炸掉…..改了n久,重构代码数据存储方式,处理方式,更改二重循环等等等等,才使代码可以几秒内建成系统…

1. 1. 1. 多种I/O实现方式的效率对比分析

使用System.currentTimeMillis()方法获取开始和结束时间,计算时间差

表格方式对比不同I/O的性能。

		SocialNetworkCircle.txt	StellarSystem.txt
Read/write	读文件	618ms	192ms
	写文件	426ms	242ms
Channel/Buffer	读文件	500ms	160ms
	写文件	2365ms	917ms
Java.nio.file.Files	读文件	764ms	144ms
	写文件	175ms	116ms

Channel/buffer读入时采用了内存映射，实际读入速度可以更快，但其读入的是二进制，要将其转化为string需要付出额外的时间。所以其对文件的复制可以远超传统方式

 

 

1. 1. Java Memory Management and Garbage Collection (GC)
      1. 使用-verbose:gc参数

使用Channel/buffer读取SocialNetworkCircle.txt文件构建系统.,进行添加新成员,计算熵,日志查询,写入文件操作

日志中的GC若无修饰则为Minor GC

Minor GC即新生代垃圾回收，Full GC针对整个堆进行垃圾回收

其中读入文件时发生18次Minor GC,3次Full GC

写入文件时发生,发生四次Minor GC

Minor GC的时间从0.1到0.8不等, Full GC为0.26,0.45和0.19.

在进行Full GC时会同时使用PSYoungGen、ParOldGen和Metaspace进行垃圾回收，同时释放新生代、年老代和元空间的内容。

GC或Full GC后面的括号内容就是本次GC产生的原因，可以看出，所有的Minor GC产生的原因都是Allocation Failure（新生代中没有足够的空间），而Full GC的原因是Ergonomics（HotSpot自动选择和调优引发的FullGC）。

由控制台可以看出，由于需要产生大量新的对象，导致内存的新生代区域不足，发生了频繁的Minor GC，尤其在读取文件时最为明显。

1. 1. 1. 用jstat命令行工具的-gc和-gcutil参数

jstat [-命令选项] [vmid] [间隔时间/毫秒] [查询次数]

首先使用命令行工具jps查看vmid

然后使用jstat 运行前

运行后

其中

参数	描述
S0	年轻代中第一个survivor（幸存区）已使用的占当前容量百分比
S0C	年轻代中第一个survivor（幸存区）的容量 (字节)
S0U	年轻代中第一个survivor（幸存区）目前已使用空间 (字节)
S1	年轻代中第二个survivor（幸存区）已使用的占当前容量百分比
S1C	年轻代中第二个survivor（幸存区）的容量 (字节)
S1U	年轻代中第二个survivor（幸存区）目前已使用空间 (字节)
E	年轻代中Eden已使用的占当前容量百分比
EC	年轻代中Eden（伊甸园）的容量 (字节)
EU	年轻代中Eden（伊甸园）目前已使用空间 (字节)
O	old代已使用的占当前容量百分比
OC	Old代的容量 (字节)
OU	Old代目前已使用空间 (字节)
M	元空间(MetaspaceSize)已使用的占当前容量百分比
CCS	压缩使用比例
YGC	年轻代垃圾回收次数
YGCT	新生代垃圾回收耗时
FGC	老年代垃圾回收次数
FGCT	老年代垃圾回收消耗时间
GCT	垃圾回收消耗总时间
PC	Perm(持久代)的容量 (字节)
PU	Perm(持久代)目前已使用空间 (字节)

新生代的大小就是伊甸园区+两个幸存区的大小。可以看出两个幸存区的占用不停的交换，每一次交换都是由于一次Minor GC。而在一次Full GC后，两个区域的占用都归为0。

新生代垃圾回收的机制为：最初，所有的对象都在伊甸园区和“From”区（某一个幸存区），垃圾回收时会将伊甸园区的所有存活的对象复制到“To”区（另一个幸存区），而在“From”区，年龄达到一定的阈值的对象会被复制到年老区，没有达到的会被复制到“To”区。完成后“From”和“To”的关系互换。此时原“From”区被清空。

1. 1. 1. 使用jmap -heap命令行工具

报错版本冲突改了一晚上,发现不知道什么原因竟然单独装了jre,eclipse还指向了那个非jdk自带的jre,重新更改eclipse设置后成功运行,用了我一晚上,哭了

此时为读入文件创建系统后,伊甸园区总大小为205M使用79.9%。From Space 90M使用率为0，To Space大小为131.使用率都是0，这是因为最后发生了Full GC，使其都被清空了，PS old generation使用61.7%,

使用jmap -histo vmid

其中[C is a char[] [S is a short[] [I is a int[] [B is a byte[] [[I is a int[][]可以看出其中有大量的char和string和存储数据的hashmap，double和Object。

1. 1. 1. 使用jmap -clstats命令行工具

这个命令真的慢,开始等了两个小时………………………关了可惜,等着还不知道能不能出来结果,最终卡死,白等了两个小时,重新开始等了几分钟出来的.

其*有4个类加载器，一共加载了994个类，占用字节1896174个，其中1个已经dead，剩余3个alive。

bootstrap classloader，用于加载核心类库，共加载了926个类，且为alive。

剩下一个ExtClassLoader,一个 AppClassLoader,一个 RBClassLoader

1. 1. 1. 使用jmap -permstat命令行工具

Jdk8不支持,使用的jmap -clstats

1. 1. 1. 使用JMC/JFR、jconsole或VisualVM工具

其中有两个峰值,每个有分为两个小的峰值,第一个的首个小峰值为读入文件,第二个小峰值为构建系统,第二个前一个小峰值为根据关系构建将要写入的字符串,第二个为写入文件

堆在读入文件呵写入文件时增大两次,由于在写入文件时我复制了一部分内容,写入后又删去了所以已用堆有一个峰值之后又恢复

装载的类为1879个,共享和已卸载均为0

活动9,守护进程8,时时峰值10,已启动总数10

1. 1. 1. 分析垃圾回收过程

在程序开始时由于读入大量数据新生代不足所以发生了多次GC,之后由于建立系统,创建了大量对象存储在不同结构中,使其再次发生多次GC,写文件时由于重新存储了大量的string类型的list,使得新时代再次不足,再次发生GC,Full GC都是由于系统调优产生的

当读入大量内容和创建大量对象时会造成伊甸园区或者“From”区占用过高时,在新生代进行垃圾回收,对象会不停的在两个幸存区间复制,从而引发多次GC

1. 1. 1. 配置JVM参数并发现优化的参数配置

更改后参数为

-Xms3072M -Xmx3072M -Xss256k -XX:+UseParallelOldGC -XX:NewSize=2048M

-XX:MaxNewSize=2048M

其中,将堆大小设置为3072M,每个线程堆栈设为256k, 使用并行的年老代垃圾回收机制，提升Full GC的速度,将新生带区域设为2048M,减少GC次数

使用Channel/buffer读取SocialNetworkCircle.txt文件构建系统.,进行添加新成员,计算熵,日志查询,写入文件操作

只在构建系统时发生了一次GC,时间为0.77s

更改参数后GC次数明显减少,Full GC也不再发生

1. 1. Dynamic Program Profiling
      1. 使用JMC或VisualVM进行CPU Profiling

使用Channel/buffer读取SocialNetworkCircle.txt文件构建系统.进行添加新成员,删除成员,日志查询,写文件操作

可以看出大部分时间花在了TCPTRansport$ConnectionHandler.run上,其次在socialMethod上(等待输入进行操作),然后是getLog,因等待输入日志的过滤条件然后是比较耗时的写操作,edgeToTrack为对10w人的广搜所以耗费了些时间,删除操作是也要进行搜索所以较慢,其他的都是执行较快的方法

1. 1. 1. 使用VisualVM进行Memory profiling

在3.4.1的条件下直接进行内存分析,如图

byte[]和char[]是因为Java里面的String操作最终都会转化为char[]的，凡是IOStream的操作都会转化为byte[],其次为Object,创建系统时生成了大量的类,几十万个,读入文件和写入文件时以string类型存储了很多数据,存储关系,等等使用的大量的map,set等,存储编号等还使用了大量的int

1. 1. Memory Dump Analysis and Performance Optimization
      1. 内存导出

使用Channel/buffer读取SocialNetworkCircle.txt文件执行耗费内存的构建系统写文件操作,使用visualVM下的堆 heap直接导出hrpof文件

1. 1. 1. 使用MAT分析内存导出文件

视图	含义
histogram	列举内存中对象存在的个数和大小
Dominator tree	该视图会以占用总内存的百分比来列举所有实例对象，注意这个地方是对象而不是类了，这个视图是用来发现大内存对象的
Top Consumers	视图展示了当前内存的占用热点
leak suspects	视图展示了可能的内存泄漏位置以及原因

Unreachable指的是可以被垃圾回收器回收的对象，但是由于没有GC发生，所以没有释放，这时抓的内存使用中的Unreachable就是这些对象。

leak suspects视图展示了可能的内存泄漏位置以及原因

Dominator Tree:

通过“引用树”的方式来展现内存的使用情况的，通俗点来说，它是站在对象的角度来观察内存的使用情况的，主要看是否存在异常的大内存对象

1. Histogram

 

列名	含义
Object	该类在内存当中的对象个数
Shallow Heap	对象自身所占用的内存大小，不包括它所引用的对象的内存大小
Retained Heap	该对象被垃圾回收器回收之后，会释放的内存大小

byte[]和char[]是因为Java里面的String操作最终都会转化为char[]的，凡是IOStream的操作都会转化为byte[],string存储了很多内容其次是存储结构等使用到的大量的hashmap.由于存储了大量的人,自建的person类也比较靠前,还有常用的double,int等

1. Dominator Tree:

通过“引用树”的方式来展现内存的使用情况的，通俗点来说，它是站在对象的角度来观察内存的使用情况的，主要看是否存在异常的大内存对象

Shallow heap	表示对象自身占用的内存大小，不包括它引用的对象
Retained heap	表示当前对象大小+当前对象可直接或间接引用到的对象的大小总和

作为当前主要运行的系统socialNetworkCircle占据了99%以上的空间,其中包含系统中的所有信息

1. Top Consumers

可以看出,占用内存最多的仍然是socialNetworkCircle,其作为当前主要运行的系统

1. Leak Suspects

与前面看到的一致,认为是socialNetworkCircle占用了99.13%,可能造成泄露

1. 1. 1. 发现热点/瓶颈并改进、改进前后的性能对比分析

可以看出其中占用最多的为hashmap和arraylist,对他们show objects by class -> by outgoing referneces，可以查看内部引用情况

Hashmap中有两个占用极大,并且一个是另一个的二倍,在程序中使用了hashmap存储社交关系,而在写文件时复制了一份,并且在写入后只剩下单向关系,正好是原来的一半,猜测其为占用内存的原因

在文件读入与写入时都是以arraylist传递的,而这些数据在创建系统后及写入文件后就没有用了,却占用了大量的空间.

于是在使用这些数据之后对其clean,并执行system.gc手动回收垃圾

执行后内存由192.4减少到131.6

1. 1. 1. 在MAT内使用OQL查询内存导出

1.OQL无法查询接口的信息,所以使用实现了接口并作为所有系统父类的ConcreteCircularOrbit进行查询.只有当前生成的社交系统类

2.查找长度大于20的字符串

查找大于1024的对象

查找物体类,当前为社交系统,所以都为Person类

1. 1. 1. 观察jstack/jcmd导出程序运行时的调用栈

如下为使用Channel/buffer读取SocialNetworkCircle.txt文件执行耗费内存的构建系统写文件操作后等待输入的调用栈

等待输入要删除的人:

等待输入选项

其中86为所在系统的代码位置,291和275为等待输入删除人姓名和等待输入操作代码的位置

1. 1. 1. 使用设计模式进行代码性能优化
2. 优化二重循环,名字不能重复将二重循环暴力求解改为list存储转set比较和list的大小.
3. 社交网络的存储结构,list嵌套的邻接矩阵存储会造成heap不足,改为map的邻接表存储,最难改的一点,数据结构变了,之前的很多方法都要改,基本将socialNetwordkCirlcle重写了一遍
4. arraylist的indexof暴力求解,循环时造成二重循环,改为map存储数据和编号
5. 将设计大量的list转为hashset与hashmap提高算法效率
6. Canonicalization思想:string作为基本类型使用时equals改用==,一些类的比较使用其在存储结构中的编号比较
7. 使用Prototype模式,使物体支持clone
8. 使用Flyweight设计模式生成电子,在相同轨道的电子只生成一个

优化前系统heap溢出,需几小时才能建立系统,优化后系统可以在5秒内建出系统,速度提高还是非常明显的