java实战场景思维导图模板_ProcessOn思维导图、流程图

分支主题

场景类

数据库

count(*)和count(1) 谁快

1、如果是innerdb 数据库引擎

两者一样快，两者最终执行的时候语句是一样的。但是比count(列名)快

直接遍历索引来查询；

2、myisam数据库引擎

count(*)快于或者等于count(1), myisam存储了表的总行数，可以直接获取总条数；

count(1)如果是第一列不为null，也是直接可以获取总条数，如果可以为null,那么就需要统计不为空的条数

count(列名)只统计不为null的数据，需要遍历整个表

性能调优

CPU突然飙升，系统反应慢，怎么排查？

导致cpu使用率飙升的原因

1、cpu上线文切换过多

1、在同一个时刻，每个cpu核心只能运行一个线程，如果有多个线程需要执行，cpu只能是通过上线文切花的方式来执行不同的线程

cpu上下文切换做的事情

记录线程执行的状态

让处于等待中的线程执行

过多的上下文切换，占用了过多的cpu资源，导致无法去执行用户进程中的cpu指令，导致用户进程中cpu相应速度过慢

上下文切换过多的场景

1、文件io操作

2、网络io

3、锁等待

4、线程阻塞

解决方式

多查询一些线程，是否处于阻塞状态中

如果是io导致，不管是网络，还是文件，

统一给这些io设置线程池，不让他们占用过多的系统资源

2、cpu资源过度消耗

过度消耗原因

1、创建了大量线程

2、有线程一直占用cpu资源，死循环

解决方式

linux系统解决

1、通过linux系统的top命令来找到cpu利用率过高的进程

2、ps -mp 进程号

查询进程信息，查看线程

2、shirt +H来找到进程中CPU消耗过高的线程

出现两种情况

cpu消耗过高的是同一个线程

通过jsatck工具根据线程id去下载线程的dump日志，然后定位到具体的代码

cpu消耗过高的是不同的线程

说明线程创建的比较多，拿几个线程id去下载线程的dump日志，

结果1、程序正常，在cpu飙高那一刻，用户访问量增大

结果2、也有可能程序不正常，线程池的创建相关有问题。

做针对性调整

docker

docker stats

1、查看docker的cpu占用率：

docker exec -it 容器编号 /bin/bash

2、进入cpu占用高的docker容器

查看容器中具体进程cpu占用率，执行top

查看进程中线程cpu占用率：top -H -p 进程号

将异常线程号转化为16进制： printf “%x\n” 线程号

查看线程异常的日志信息：jstack 进程号|grep 16进制异常线程号 -A90

各种监控系统辅助我们排查

线上服务内存溢出如何定位排查

排查问题方式

1、先获取堆内存快照文件

1、通过设置jvm参数

让jvm发生内存溢出的时候自动生成dump文件，并且存放在某个固定路径下面

2、通过执行dump命令来获取当前jvm的内存快照

2、通过mat工具分析dump文件

dump文件分析工具

1、mat工具

专门用来分析dump文件的

2、jprpfile工具

3、解析dump文件，得到内存统计信息总览

4、点击dominator Tree

dump文件中内存占用情况

5、获取到内存占用最高的类

6、然后再查看这个类中相信的内存占用情况

根据代码的情况惊醒调整

内存

怎么计算一个对象的内存大小？

1、通过工具类计算

1、Unsafe类计算

2、使用<dependency>
<groupId>org.apache.lucene</groupId>
<artifactId>lucene-core</artifactId>
<version>4.0.0</version>
</dependency> 包下面的 RamUsageEstimator 类种的方法计算

2、通过手动计算

1、计算对象实体数据

1、对象头数据，实例数据，对齐数据

2、计算数组数据

子主题

计算对象都数据，数组长度，实体数据，对齐数据

1.对象的属性；（定义多少字段，需要分配相应的字段）如果没有字段，内存分配这个也是没有的；
2.对象头；（固定大小的12个字节，这是64位操作系统，32位系统的是4个字节）
3.对齐数据（假如一个对象的实际存储空间的数据，不是8位的整数倍，
但是需要填充空位，填充到8 的整数倍，（这个是64位的虚拟机））对齐数据有时候有，有时候没有

内存溢出其他线程还能工作吗？

可以，造成堆内存的线程会被销毁，所以这个线程创建的内存对象也会被回收，
其他线程还是可以获取到充足的内存空间来支持程序运行

调优

大的分类

业务调优

代码复用优化

性能调优

调优层面

设计层面

设计层面优化师优化手段的上层，根据系统的难点和潜在的问题，评估设计出合理的设计方案

具体方式

缓存使用

对象池设计

常量池

连接池

线程池

IO优化，选择多路复用

消息队列根据具体业务，设置对应的确认机制

使用序列化效率高的组件

零拷贝

io多路复用

代码层面

代码层面优化方式

合理使用设计模式

单例设计模式

减少对象的创建，减少内存消耗

减少对象的频繁创建

字符串优化

字符串操作避免内存泄露

切割查找选择最快方式

容器优化

根据当前业务查询多还是修改多，合理选用对应的容器

局部变量的容器，选择对应的操作快速的线程不安全的容器

容器的初始化长度可以，根据预估的数据量

位运算替代除法操作

避免二维数组使用

减少静态方法

GC不会回收静态方法占用的元空间数据

满足业务的情况下使用基本类型替代对象

对象需要开辟堆内存，基本类型需不要堆内存

代码中减少对第三方循环调用，第三方提批量接口

合理多使用switch 语句替代if else

合理的使用空间换时间，或者时间换空间的思想

时间复杂度，空间复杂度

降低资源竞争

锁对象使用合理

乐观锁

io操作释放对应的资源

代码中可以手动将不再使用的大对象手动回收

同步变成异步

算法优化

针对搜索时间，内存大小设计合理的数据结构

JVM层面

编译优化

可以调整减少执行次数，再进行热点编译，针对一些执行频率很高的代码，可以在前期优化时间；

cpu核数，内存调整

根据cpu数量，内存大小和各项极限指标（qps,99线，并发量）的函数关系，做适当调整

根据对内存，cpu告警信息做适当调整

数据库层面

具体方式

sql优化

1、合理设置索引

2、合理的提前生成统计数据

3、连接池优化

4、减少关联查询

库表结构优化

1、合理分库分表

2、合理冗余字段

数据硬件优化

内存更大，磁盘更大， cpu核数更多，运算速度更快

数据库参数优化

数据库日志刷盘策略

缓冲池大小

操作系统层面

磁盘，内存，cpu,

文件最大句柄数量

会影响io多路复用

优化评定指标

95线，99线，999线

cpu时间

内存分配

磁盘吞吐量

网络吞吐量

并发量

调优前注意事项

明确调优目的，不要为了调优而调优，盲目调优可能适得其反

数据加密算法

不可逆加密

加密方式

MD5

概述

信息摘要算法5

特点

单向不可逆，无法解密

产生一个固定长度的散列码

使用场景

密码存储

信息完成性校验

HMAC系列

概述

散列消息鉴别码

特点

SHA系列

特点

单向不可逆，无法解密

产生一个固定长度的散列码

使用场景

密码存储

信息完成性校验

不可逆特点

单向不可逆，无法解密

产生一个固定长度的散列码

可逆加密

非对称加密

概述

公钥加密，私钥解密

非对称加密方式

RSA

DSA/DSS

特点

1.比对称加密更加安全可靠；

2.加密解密比对称加密慢很多

使用场景

HTTPS建立SSL连接中有一个步骤就是，将服务端的公钥加密用于对称加密的密钥；也就是把数据传输的对称加密的密钥发送给服务端，这样客户端和服务端都知道了实际做数据传输的对称密钥了

对称加密

概述

加密解密都是用的同一个密钥

对称加密方式

DES

3DES

AES

特点

1.加密解密速度快；

2.适用于大量数据加密

3.由于需要把密钥传递给需要用的对接方，在传递的密钥的过程中容易被人抓包，造成数据不安全；

场景

HTTPS建立SSL连接之后，客户端和服务端使用的就是对称加密来传输数据；主要就是利用对称加密解密速度快的优势

对称/非对称加密区别

性能

对称加密性能高于非对称加密

安全性

非对称加密安全性比对称加密安全性高

加密解密方式

对称加密，加密解密都是用的同一个密钥；非对称加密，加密解密密钥是分开的；

可逆/不可逆区别

可逆：可以通过解密的密钥获取到加密之前的数据；不可逆：数据是没有办法做解密操作，无法拿到解密之前的数据；

加密盐

作用

增加数据被破解的难度

让相同的数据在被加密之后显示的数据是不一样的；

接口幂等性

查询和修改操作都是幂等；添加和删除不是幂等

分布式环境下怎么保证接口的幂等性

幂等性概述

1.用户对于同一操作发起的一次请求或者多次请求结果都是一样。

具体操作

查询操作

天然幂等的

删除操作

删除一次和删除多次可能返回的数据不是一样

更新操作

如果把某个字段的值设置为1，那么不管多少次都是幂等

如果把某个字段值加1，那么就不是幂等

添加操作

重复提交会有幂等性问题

幂等性解决方案

1.通过代码逻辑判断实现

一般场景：代码中通过代码逻辑判断

支付场景：通过唯一的订单id来判断重复

2.使用token机制实现

支付场景：页面跳转的时候获取全局唯一的token，把token缓存起来；等到提交到后台的时候，再校验token是否存在，第一次提交成功就会删除token

使用场景：分布式环境

3.乐观锁

分布式环境中，做重复校验，直接用乐观锁实现

使用场景：分布式环境

延时任务

redis

实现方式

通过Redis的key的事件通知机制

缺点

Redis的事件通知，消息只会发送一次，不管客户端是否有收到（无消息确认机制）

使用场景

需要对某些key的改变做监控

消息队列

RocketMQ

RocketMQ设置固定延时时间发送消息

缺点

延时的消息时间只能是十几个固定的延时时间

使用场景

RabbitMQ

实现方式

1.正常队列不设置消费者，给单个消息设置超时时间；

2.设置死信队列和死信队列的消费者，把超时未发送的消息发送到死信队列；

使用场景

kafka

实现方式

时间轮定时任务

使用场景

定时任务

实现方式

先对数据先进行落库，再对数据库进行定时轮询

缺点

对数据库压力大

使用场景

java延时队列

实现方式

实现Java的延时队列，这是固定的延时时间；

高并发问题

接口限流

限流方式

验证码

使用场景

容器限流

NGINX

Tomcat

队列

手动控制某些接口访问

gateway

使用场景

服务器限流

Semaphore类控制并发访问数量

任务线程池控制方式

锁

限流算法

令牌桶

实现

使用场景

漏斗桶

实现

使用场景

滑动窗口

实现

使用场景

计数器

实现

使用场景

子主题 5

流量计算方式

滑动窗口

子主题 2

子主题 3

秒杀系统设计

秒杀系统的特点及对应解决方式

1.读多写少

缓存

2.高并发

限流

负载均衡

缓存

异步

队列

3.资源访问冲突

不同层级对应解决方案

应用层

控制方式

按钮控制

点击之后，一段时间之后才能再次被点击

验证码控制

需要收到验证码才能点击

控制目的

降低用户秒杀系统的点击频率

网络层

CDN

负载层

负载均衡，反向代理，限流

降低服务器访问压力

服务层

缓存，异步，队列，限流，原子操作

降低对数据库的压力

数据库

乐观锁，悲观锁

CDN作用

lua脚本为啥可以原子性执行

redis缓存

数据存入缓存

首页

banner

List集合

三个豆腐块

List集合

为你推荐条件

List集合

竞拍大厅

筛选条件

骨架星级

Hash表

注册地

Hash表

车龄

Hash表

里程

Hash表

车辆级别

Hash表

排放标准

Hash表

车源属性

Hash表

燃料类型

Hash表

查询条件

场次

Hash表

拍场模式

Hash表

所有品牌车系

List集合

热门品牌

Hash表

业务城市数据

List集合

查询结果集

为你推荐

通过zset排序用户出价的品牌车系；每次出价的时候异步去更新redis的记录以及数据库

心愿单

心愿单的查询条件