Java工程师技术路线
2020-06-28 10:32:25 8 举报
AI智能生成
java工程技术路线
作者其他创作
大纲/内容
Java基础
集合
Collection
List
ArrayList
LinkedList
CopyOnWriteArrayList
Set
CopyOnWriteArraySet
Queue
Deque(双端队列)
AbstractQueue(非阻塞)
PriorityQueue
ConcurrentLinkedQueue
BlockingQueue(阻塞)
ArrayBlockingQueue
LinkedBlockingQueue
PriorityBlockingQueue
DelayQueue
SynchronousQueue
Map
HashMap(unsafe)
底层结构
红黑树
Hash数组
ConcurrentHashMap
底层结构
红黑树
hash数组
CopyOnWriteMap
TreeMap
底层结构
红黑树
.....
JVM
垃圾回收
判活方式
引用计数法
缺点(循环引用问题)
GcRoot
root判断对象
栈帧中的变量引用表
方法区中的静态引用对象
方法区中常量引用对象
本地方法栈中的JNI引用对象
回收方式
复制算法
需要额外的存储空间
标记清除算法
会产生大量的空间碎片
会出现没有连续的空间存储对象
整理标记清除算法
需要进行对象的空间移动,消耗大量性能
回收分区
年轻代
老年代
STW(Stop The World)
垃圾回收所做的暂停机制
通过safepoint机制实现
垃圾分区升级时机
年轻代存活时间年龄达到设置15(1111)
年轻代没有做够的存储空间
HotSpot算法实现
枚举根节点
gc root的所有root
安全点
找到一个稳定执行态,保证jvm的堆不在发生变化,这样可以保证安全执行gc root
主要不离开安全点,jvm便能够在垃圾回收的同时,继续运行这段本地代码
程序只有到达安全点才能进行暂停开始gc
安全词
GC pause
目前存在的回收算法
CMS
初始标记(STW)
并发标记
重新标记(STW)
并发清除
G1
ZGC
对象创建位置
并不是没有的对象都会建立在堆上面
内存模型
堆
GC主要回收区
存放java对象
多线程共享,jvm中最大的内存空间
会出现内存溢出
虚拟机栈
方法执行的栈针
存储java执行时局部变量,以栈帧形式存储,含数据类型和对象引用,执行后就释放
线程私有,生命周期与线程相同
出现栈溢出和内存溢出的情况
局部变量所需的内存空间在编译时生成,不能动态扩容
本地方法栈
同虚拟机栈,只不过是用来执行native方法
方法区
存储静态变量,加载的类信息,常量,运行时常量池等
线程共享
抛出内存溢出
很少有垃圾回收,只会在类卸载时
程序计数器
程序执行的顺序,执行字节的行号的指示
异常处理,线程恢复等功能
线程私有,占用内存小
不会出现内存溢出
每个线程都有独立的计数器
直接内存
NIO类(JDK1.4引入)中基于通道和缓冲区的I/O方式 通过使用Native函数库 直接分配 的堆外内存
通过一个 存储在Java堆中的DirectByteBuffer对象 作为这块内存的引用 进行操作,从而避免在 Java 堆和 Native堆之间来回复制数据,提高使用性能
类加载
加载顺序
加载
连接
验证
准备
解析
初始化
使用
销毁
ClassLoader
原子类(Atomic*)
原理
Lock
锁分类
无锁
乐观锁
锁思想,假设大部分情况下是不会有锁冲突的
mysql+version的设计
Java中CAS
悲观锁
锁思想,假设所有情况都会有冲突,进行整个锁的锁定
synchronized修饰的方法和方法块
ReentrantLock
自旋锁
自适应自旋锁
偏向锁
轻量锁
重量锁
锁原理
AQS
volatile
特征
防止重排序
原理
内存屏障
Load,load
Store,store
load,store
store,load
写操作前插入store,store
写操作后插入store,load
读操作前插入load,load
读操作后插入load,store
可见性
原理
MESI缓存一致性协议
Bus总线(宽带限制)
CAS
内存屏障
happen-before
操作系统锁语义
锁实现
闭锁
synchronized
锁升级
锁原理
CountDownLatch
栅栏
CyclicBarrier
信号量
Semaphore
IO
NIO
BIO
AIO
SPI
LoadServer
Java内存模型
主内存
应用内存
Thread
线程池
线程状态
新建(new)
运行(Runable)
等待(Wait)
阻塞(block)
死亡(deal)
线程调度方式
抢占式
协同式
数据库
Mysql
存储引擎
InnoDB
底层结构
B+树
存储
按照页来存储16KB大小,查询加载时会直接加载cachePage
索引
索引建立
索引规则
复合索引有最左匹配观念
索引实现分类
聚簇索引
非聚簇索引(二级索引)
索引功能分类
主键索引
如果没有指定索引会有6字节的自己生成的隐式主键
唯一索引
普通索引
复合索引
外键索引
全文索引
MVCC机制
DB_TRX_ID
事务ID(6byte),每次执行一次事务进行+1
DB__ROLL_PT
回滚指针(7byte),指向ROLLBACK_SEMENT的undolog数据
undolog以链表的形式存储所有历史记录
undolog以链表的形式存储所有历史记录
DB_ROW_ID
(6byte)未指定主键ID时生成的隐式ID
ReadView
事务视图
已提交事务
活跃事务
未开始事务
流程示例
MyISAM
数据库锁机制
行锁
表锁
乐观锁
悲观锁
事务隔离级别
Read uncommitted(未授权读取、读未提交)
Read committed(授权读取、读提交)
Repeatable read(可重复读取)
Serializable(序列化)
事务特性
原子性
一致性
隔离性
持久性
事务传播机制
执行过程(基础架构)
权限控制验证
查询是否存在缓存
词法分析
语法分析
优化sql
执行sql
存储缓存
返回查询数据
sql语句执行过程
1. from产生笛卡尔积生成V1虚表
2. on 过滤条件产生V2
3. 根据join类型操作然后产生V3
4. where 条件过滤V4
5. group by 操作产生V5
优化方案
WHERE 左侧的条件查询字段不要使用函数或者表达式
EXPLAIN 查看执行计划优化SQL(show warnings显示优化sql)
确定语句数量时使用limit 1
尽量不使用select * ,查询具体的字段比较好
为每张表设置ID
不在where条件中判断NULL
使用 BETWEEN AND 替代 IN
尽量不使用!= ,>= ,<= 等范围性查询
建立索引
设计数据库字段尽量不为NULL
选择合适数据库引擎
水平或垂直划分
尽量不使用复合语句
Like 语句尽量使用后通配
in(小表作为内部条件),exists(小表作为外部条件)
redis
支持数据类型
Zset
可排序set集合
ziplist
使用紧挨着压缩列表实现,第一个存放数据,第二个存放分数
skiplist
字典
存储数据和分数的映射
跳跃表
从小到大存储分数
list
hash
set
string
存储512M数据
redis底层数据结构
type:对象类型
OBJ_STRING 0
OBJ_LIST 1
OBJ_SET 2
OBJ_ZSET 3
OBJ_HASH 4
encoding:对象编码
OBJ_ENCODING_RAW /* Raw representation */ 动态字符串
OBJ_ENCODING_INT /* Encoded as integer */ 整数
OBJ_ENCODING_HT /* Encoded as hash table */ 字典
OBJ_ENCODING_ZIPLIST /* Encoded as ziplist */ 压缩列表
OBJ_ENCODING_INTSET /* Encoded as intset */ 整数集合
OBJ_ENCODING_SKIPLIST /* Encoded as skiplist */ 跳跃表
OBJ_ENCODING_EMBSTR /* Embedded sds string encoding */ emb编码的动态字符串
OBJ_ENCODING_QUICKLIST /* Encoded as linked list of ziplists */ 压缩列表
lru:
refcount:引用计数
*ptr:指向底层数据结构
优势
丰富的数据类型
高性能
R: 110000/s
W: 81000/s
原子性
多操作使用MULTI 和 EXEC 指令
publish/subscibe
key过期
redis架构
集群
哨兵(sentinel)作用
集群状态监控
主副进程的正常工作监控
消息通知
预警
leader选举
leader挂掉都选举新的leader
故障转移
主节点和备用节点之间的数据转移
配置中心
通知客户端更新主节点地址
高可用
哨兵集群
数据丢失的场景
主备复制的时候
发生脑裂的时候
持久化
AOF(Append Only File)
记录每一次操作的命令(查询除外)
触发机制
no
等待操作系统数等据缓存同步到磁盘(速度快,数据没法保证)
always
每次发生变化立即写(速度慢,安全性高)
everysec
每秒发生异一次操作(默认,快,丢失1s的数据)
重写机制
解决aof会存在大量的重复操作,导致让日志文件越来越大,重写使其瘦身
bgrewriteaof命令,将内存的数据存储在临时文件中,同时fork子线程将文件重写
新文件替换旧文件方式,占用内存大
大于配置的aof文件,系统触发重写瘦身
优点
更好保证数据不会丢失
即使有人清空数据,也可以根据日志文件恢复
缺点
文件大
恢复时间慢
效率低
RDB(Redis DataBase)
以快照的方式存储,持久化到磁盘
会单独fork一个与主线程相同的线程处理(cow)
开机快
写入持久化文件快
大数据量的恢复,备份,复制
触发机制
save命令(不使用)
不会fork子线程,通过阻塞的方式,直到rdb写入完成
bgsave命令(空间换时间)
fork子线程,只会在fork的时候阻塞,子线程完成服务
缺点
会丢失最后一次快照
对数据一致性要求低的情况使用
AOF+RDB(redis4.0)
通过bgrewriteaof机制
先进行rdb模式快照,然后进行aof命令增量
同时拥有两个优点
缓存
JVM缓存
自定义缓存(Map,List等实现)
Google guava cache
Ehcache
分布式缓存
Redis缓存
缓存设计
缓存雪崩
解决方案
对缓存数据加随机失效时间,保证不会同时大部分失效
使用锁或者队列来控制直接访问DB的流量
设置缓存标志,当缓存失效时去DB层刷新缓存
·
描述
某个时间段,数据统一的失效,给服务造成压力
缓存穿透
解决方案
布隆过滤器
缓存null数据,过期时间设置短
描述
查询的数据数据在缓存上不存在,每次必须查询DB
缓存击穿
解决方案
查询DB后,再次缓存
使用Mutex互斥锁,当查询为空时不立即去DB拿数据,先进行加锁,然后进行DB查询后set缓存。当操作失败重试整个获取缓存操作
描述
查询的数据在缓存中存在,但是已经失效,导致查询DB
memcached缓存
架构
Spring
AOP
IOC
Spring boot
配置化机制
与spring mvc的区别
中间件
Mybits
Rabbits
消息丢失场景
生产者发送是网络问题丢失
开启事务,同步阻塞性能不佳
开启confirm模式,异步模式,通过通知的方式
MQ内部消息丢失
开启持久化
消费者消息丢失
关闭自动ack,通过手动ack来通知
消息乱序问题
消息队列进行拆分
同一个订单等进入同一个队列
一个消费者一个队列的进行对应
Kafka
消息丢失场景
在leader挂机后进行重新选举leader不存在要消费的数据
topic设置replication.factor,值必须大于1,给partition设置多个备份分区
min.insyc.replicas 值大于1,保证至少有一个 follower 至少有一个与主节点联系
消息乱序问题
放入时,确定同一个ID即可放在同一个partition中
消费时,如果多线程消费,需要在多线程前加队列,保证同一个ID放入同一个队列中
Zookeeper
RocketMQ
消息丢失场景
生产者发送时网络抖动失败
生产者发送half消息,确定是否发送成功
成功后执行生产者核心逻辑
核心逻辑执行失败则回滚,并通知Mq删除half消息
执行成功则进行commit half消息
在写入磁盘还没完成,rocketMq挂机
持久化的磁盘损坏
消息消费未完成,rocketMq挂机
所以消息消费积压问题解决方案
先建立几倍的临时消费队列和消费者,来进行消费堆积的消息
关闭旧的消费者,进行性能修复
RPC
Dubbo
轻量级的rpc框架
使用场景
透明化的调用方式
软负载均衡和容错机制
服务自动注册发现
核心功能
Remoting
网络通信架构
cluster
服务架构
registry
注册服务
核心组件
provide
服务提供方
consumer
服务消费方
registry
注册服务
monitor
监控服务
container
运行服务容器
服务流程
描述
gRPC
thrift
Spring Cloud
Eureka(注册中心)
Zuul网关
Gateway网关
Ribbon负载均衡
Feign服务调用
Hystrix熔断器
Rest
一致性协议
子主题
网络知识
网络协议
OSI七层
应用层
表示层
会话层
传输层
网络层
数据链路层
物理层
五层协议
应用层
传输层
网络层
数据链路层
物理层
四层协议
应用层
传输层
网络层
网络层接口
http
TCP
三次握手
四次挥手
安全保证
流量控制
拥塞控制
ARQ
UDP
容器
Docker
K8s
分布式知识
分布式ID
UUID
优点
生成方式简单
缺点
无含义
存储mysql中频繁变动
不具有自增性
数据库自增
优点
ID自增,速度快
缺点
单机DB会成为瓶颈
号段模式
Redis
inc
SnowFlake(推特)
TingID(滴滴)
idgenerator(百度)
Leaf(美团)
分布式事务
2PC
TM(事务管理者)
1. 参与者确认能否进行事务提交
2. TM进行汇总所有的确认消息,如果有一个失败则进行回滚
3. TM确认所有通过,进行提交
存在问题
确认提交后,参与者失败,出现事务不一致
同步阻塞,性能低
单机故障管理TM故障,则瘫痪
3PC
TM(事务管理者)
1. 参与者确认事务能否进行提交
2. TM汇总确认信息,如果失败就进行回滚
3. 确认通过进行预提交,参与者确认是否能够提交成功
4. 提交失败进行回滚
5. 确认预提交成功,则进行正式提交
存在问题
存在2PC相同问题,真正提交时网络等问题,参与者为接受到等出现数据不一致(相对于2PC可靠性相对更高)
单机故障问题
TCC(补偿机制)
1. 预先占用资源
2. 确认实际操作
3. 取消占用
消息中间件
柔性事务
通过逻辑保证事务
存在问题
不支持回滚
seata框架
基础理论
BASE
基本可用
最终一致
软状态
分布式锁
Redis
redis事务实现
NX实现
Redisson
lua脚本加锁
watch dog实现失效延时
数据库DB
乐观锁
版本号控制
并发性
不可重入
增加重入字段解决
无自动失效
增加失效时间
非公平锁
中间表加队列
悲观锁
select ... from... where... uodate
where条件得使用索引,不然会锁表
ZooKeeper
创建临时节点
判断是否是第一个节点
是:第一个获取锁成功
否:失败
算法知识
分治算法
动态规划
贪心算法
回溯算法
分支界限法
排序算法
快排排序
冒泡排序
堆排排序
选择排序
插入排序
希尔排序
桶排排序
基数排序
数据结构
数组
具体实现
Hash表
栈
队列
优点
高性能的随机访问能力
适合多读的场景
缺点
插入删除操作O(n)
链表
树
图
设计模式
单例模式
饿汉式
class加载时构建,在static块或者直接静态实例化
懒汉式
double check机制+volatile
使用静态内部类
枚举式
操作系统
收藏
0 条评论
下一页
为你推荐
查看更多