一、线程、协程、进程的区别

进程：进程是计算机中资源分配的最小单位。一个进程有自己的内存空间、处理器状态以及文件描述符等，能够独立地运行和管理多个线程。不同的进程之间相互独立，不能直接共享内存，需要通过进程间通信（IPC）来进行数据交换。进程之间切换的开销比较大，但进程之间的隔离性好，可以更好地保证系统安全性。

线程：线程是一个进程内部的执行单元，每个线程有自己的栈空间和寄存器等，但它们与所属进程共享内存和文件描述符等资源。线程之间切换的开销比进程小，但由于线程之间共享内存，需要注意线程之间的同步和互斥问题。

协程：协程是一种用户态的轻量级线程，可以在同一个线程内实现并发处理，而且协程之间切换的开销很小。协程不使用操作系统提供的线程调度机制，而是通过程序员手动控制协程的切换。协程之间共享内存，需要注意同步和互斥问题。

二、内存溢出

定义：

内存溢出是内存占比越来越高，最终导致运行缓慢或者是程序崩溃，因此需要及时发现和解决内存溢出问题。要注意内存管理，及时回收无用的内存避免内存泄漏问题的出现。内存溢出不仅限于app，在所有需要动态分配内存的程序中都有可能发生内存泄漏问题

内存溢出测试原理：

模拟大数据量：通过创建大量对象、加载大文件、循环执行等方式，在程序运行时占用大量内存，在不同的内存使用情况下进行测试。
压力测试：使用性能测试工具如JMeter、LoadRunner等模拟多用户同时访问应用程序，在高并发情况下监控内存使用情况，观察系统是否存在内存泄漏等问题。
内存分析工具：使用内存分析工具如jmap、jvisualvm等对程序进行分析，定位内存泄漏点，找出引起内存泄漏的原因。
代码审查：对程序进行代码审查，找出可能导致内存泄漏的代码，例如未关闭打开的资源、未释放分配的内存等。
长时间稳定性测试：在相同的测试环境下连续运行程序数小时或数天，观察程序是否存在内存泄漏问题，以及在长时间运行后内存的使用情况。

三、安卓性能测试-移动端性能测试关注指标

a、性能测试分为：服务器性能测试，移动端性能测试

安卓移动端性能测试可使用android studio工具去监控能耗、内存、cpu、网络（但是限制比较多，版本限制、代码库限制）
Perfdog（收费）
Mobileperf：（已经是一年前的更新的代码，后续没有维护了。源码有些支持到安卓10）阿里开源、封装了很多常用的指标监控、基于python：源码可拓展

备注：安卓移动端性能测试目前测试的比较少，之前也有使用过gt这个工具进行移动端的测试

b、安卓性能测试指标

启动方式（需要多次反复执行，取得平均数和最大值）：

冷启动（关闭程序之后再次启动）
热启动

响应时间：安装、启动、跳转
Fps帧率（fps指标是衡量app画面每秒传输的帧数，每秒帧数越多，操作app的动作越流畅）
Cpu：cpu总体使用率、应用程序apu占有率等
内存：与其他进程共享内容、app独占的私有内存等
Gpu
网络
能耗

四、服务器性能测试指标

做性能测试前，需求文档中需要有一个指标，可以向产品团队要，具体的压测数据是根据实际用户量、最大用户量等数据来参考并发数量。

a、服务端系统性能常用指标

Tps：服务端每秒处理请求的数量，是最直观反应系统的处理能力 TPS是由RPS（每秒发出的请求数）、网络延迟、服务端本身的处理速度这3个因素决定的。压测时需要保证网络状态良好及rps，rps是由由测试工具决定的。一个压测工具本身的加压性能也很重要。如果TPS指标比较高，工具本身做不到，就没法测试了。例如jmeter单机压测最大就是几千到一万之间，其中受硬件、程序复杂程度等多种因素影响，具体情况具体分析。最理想的状态下，tps=rps
响应时间：服务端处理请求耗费的时间
并发连接和并发用户：并发连接数是服务端和客户端建立的 TCP连接的数量 并发用户数是服务端同时服务的 用户的数量 。用户的一个操作可能引发多个并发连接
Cpu/内存/磁盘/网络负载
错误率
备注：不管是用户端性能还是服务端性能除列出的指标外还有很多指标，具体需要看需求关注及要求的指标是哪些

五、性能测试流程

性能场景分析和创建
压测脚本编写和调试
脚本执行
指标监控
定位瓶颈
性能调优
输出测试报告

六、接口加解密

如果是遇到接口加密时，需要编写程序进行加解密可以先找开发要加解密的jar包在线程组中导入【每个公司的加解密是不同的，要单独写一套加解密算法。算法也可以叫开发给。不会的就让开发协助一下】

七、同步定时器的作用

当压力瞬时变大时，把所有的线程都创建好了才开始施压。例如创建了100个用户成功之后再去请求登录接口，都请求登录接口完毕后再去请求下一个接口（就是会相互等待，等第一个接口全部结束再进行下一个接口）

每一个线程最好就是创建一个账号（若是会token过期，就尽量一个压测一个账号）

八、jmeter分布式压测

为什么要做分布式（最好用linux系统，必须是局域网才能用分布式去关联执行机）

单机端口不够用。Windows端口号只有4000个，短时间跑大量的请求会导致报错端口号被占用。解决方式：更改端口号
单机性能限制（cpu、内存不足）。jmeter最大支持1000左右的并发用户数，jmeter是java应用，对cpu跟内存消耗比较大，模拟大并发时很容易就java内存溢出从而导致瓶颈，性能结果不准确【jmeter单机压测时最好不要超过300-400并发数】
单机带宽不够
负载过高时性能损耗大，延时高。数据不准确

主从机环境配置

前提配置

master跟slave中jmeter版本及jdk版本需要一致

jmeter可以安装后发送给需要同步的设备再进行安装-环境配置
jdk可以下载相同的版本-环境配置（这里同步设备版本的时候环境变量配置踩了不少坑，java-version一直跑不了，最后认真检查环境变量是因为之前的jdk在c盘，后来同步版本后jdk在d盘，环境变量还有部分仍是在c盘导致出错）
如果使用了csv文件，则需要使用相对路径且该csv文件也需要放在相同路径下
关闭防火墙
保证在同一个局域网内。可以使用ping的方式。cmd调出命令行，输入ping slave机器ip【查看是否可以ping通】

master配置（主机/控制机）

修改jmeter-bin-jmeter.properties 文件中的remote_hosts

修改jmeter-bin-jmeter.properties 文件中的server.rmi.ssl.disable=true

修改jmeter-bin-jmeter.properties 文件中的mode=Standard

启动服务。打开cmd命令后输入指令：jmeter-server -Djava.rmi.server.hostname=ip_address
备注：这条命令中的ip_address用的是主机（master）的ip

slave配置（压力机）

修改jmeter-bin-jmeter.properties 文件中的server_port跟remote_hosts

修改jmeter-bin-jmeter.properties 文件中的server.rmi.ssl.disable=true
修改jmeter-bin-jmeter.properties 文件中的server.rmi.port 端口

启动slave服务：打开cmd命令后输入指令：jmeter-server -Djava.rmi.server.hostname=ip_address
备注：这条命令中的ip_address用的是压力机（slave）的ip
最后在主机上执行命令：jmeter -n -t D:\test\Distributed.jmx -r -l D:\test\result.jtl（命令不是固定的，可以加上其他你需要的参数）
备注：

压测脚本master会分发给slave
slave执行时可以不器用gui
执行完成后slave会把结果回传给master，master会汇总信息
执行机少的情况下，控制机也可以充当执行机（但是最好不要，因为会加大损耗控制机的资源）
若有多台slave则相同的操作配置
并发数上w或者是百万时可以使用阿里云压测服务，可生成报告

遇到的报错

在配置时一直出现这个报错，各项都检查过了，还是报错。最后在master跟slave机器上都启动了服务，即执行jmeter-server -Djava.rmi.server.hostname=ip_address命令后，居然就可以正常跑了！

九、性能瓶颈分析

tps上不去的原因分析：

压力机压力不够
网络带宽。单位时间内网络传输数据量过大，超过了带宽处理能力
数据库连接数太少，最大连接数不够
cpu、内存、磁盘硬件资源达到瓶颈
中间件redis存在瓶颈
存在大量线程阻塞、线程死锁等
中间件消息队列拥堵

响应时间过长的原因

服务器硬件资源cpu、内存、磁盘达到瓶颈
网络问题导致，例如丢包、带宽不够等
线程死锁、阻塞等问题
中间件如消息队列拥堵
数据库的sql不够优化，没有索引、联合索引失效、数据库连接数不够

cpu飙高

算法复杂。例如加解密算法
序列化操作多
代码bug，例如死循环

jmeter压测