Appearance
面试
数据库
语法
GROUP BY
- 满足,
select子句中的列名必须为分组或者列函数 - 列函数对于
group by子句定义的每个组各返回一个结果
HAVING
- 通常与
group by子句一起使用 where过滤行而having过滤组- 出现在同一sql的顺序
where>group by>having
索引
B树
对于一个m阶的B树则有:
根节点至少包括两个孩子
树中每个节点最多含有m个孩子(m>=2)
除根节点和叶节点外, 其他每个节点至少都有ceil(m/2)个孩子
所有叶子节点都位于同一层
假设每个非终端节点中包含有n个关键字信息, 其中
a.
K[i]$(i=1…n)$为关键字, 且关键字按照顺序升序排序,K[i-1]<K[i]b. 关键字的个数n必须满足:
[ceil(m/2)-1]<=n<=m-1c. 非叶子节点的指针:
P[1], P[2], ……, P[M]; 其中P[1]指向关键字小于K[1]的子树,P[M]指向关键字大于K[M-1]的子树, 其他P[i]指向关键字属于(K[i-1], K[i])的子树如果经过新增导致节点个数大于
m-1, 则通过向上拆分中间值达成新树如果经过删除导致节点个数小于
m/2, 则通过合并上层关键字与包含过小节点在内的两侧的叶子, 形成新的叶子, 达成新树, 如果此时叶子大于m-1则进行拆分操作
B+树
- B+树是B树的变体, 优势有
- B+树的磁盘读写代价更低
- B+树的查询效率更加稳定
- B+树更有利于对数据库的扫描(范围查询效率更好)
- 非叶子节点的子树指针与关键字个数相同
- 非叶子节点的子树指针
P[i], 指向关键字值(K[i], K[i+1])的子树 - 非叶子节点仅用来索引, 数据都保存在叶子节点中
- 所有叶子节点均有一个链指针指向下一个叶子节点
Hash
- 仅能满足
=、IN, 不能使用范围查询 - 无法被用来避免数据的排序操作
- 不能利用部分索引键查询
- 不能避免表扫描
- 遇到大量Hash值相等的情况后性能并不一定比B树索引高
BitMap
<关键字, 开始, 结束, 位图>- 适用于值被限定在某几种的情况.(比如性别)
- 锁的粒度非常大, 会占用一整个位图, 不适用于高并发
密集索引和稀疏索引
- 密集索引文件中的每个搜索码值都对应一个索引值
- 稀疏索引文件只为索引码的某些值建立索引项
- 对于InnoDB
- 若一个主键被定义, 该主键则作为密集索引
- 若没有主键被定义, 该表的第一个唯一非空索引则作为密集索引
- 说不满足以上条件, innodb内部会生成一个隐藏主键(密集索引)
- 非主键索引(稀疏索引)存储关键键位和其对应的主键值, 包含两次查找
- 延伸问题
- 如何定位并优化慢查询sql
- 根据慢日志定位慢查询sql
slow_query_log: 是否开启慢日志slow_query_log_file: 慢日志存储地址long_query_time: 大于多少秒时记录慢日志slow_queries: 慢查询的数量
- 使用explain等工具分析sql
type: system>const>eq_ref>ref>fulltext>ref_or_null>index_merge>unique_subquery>index_subquery>range>index>allextra:- Using filesort: 表示MySql会对结果是用一个外部索引排序, 而不是从表里按索引次序读到相关内容. 可能在内存或者磁盘上进行排序. MySql中无法利用索引完成的排序操作称为"文件排序".
- Using temporary: 表示MySql在对查询结果排序时使用临时表. 常见于排序order by和分组排序group by.
- 修改sql或者尽量让sql走索引
- force index(primary)
- 根据慢日志定位慢查询sql
- 联合索引的最左匹配原则
- MySql会一直向右匹直到遇到范围查询就停止匹配
=和in可以乱序, MySql的查询优化器会帮你优化成索引可以识别的形式
- 索引不是建立的越多越好
- 数据量小的表不需要建立索引, 建立会增加额外的索引开销
- 数据变更需要维护索引, 因此更多的索引意味着更多的维护成本
- 更多的索引意味着也需要更多的空间
- 如何定位并优化慢查询sql
索引失效
- 违反最左匹配法则
- 在索引上做任何操作
- 类型不一致导致的索引失效
- 索引未覆盖
- 使用不等于
- like以通配符(%)开头
- 字符串不加单引号
- 如果OR连接的是同一个字段,那么索引不会失效,反之索引失效。
NOT IN、NOT EXISTS导致索引失效
锁
- 锁的分类
- 粒度: 表级锁、行级锁、页级锁
- 级别: 共享锁、排他锁
- 加锁方式: 自动锁、显式锁
- 操作: DML锁(对数据进行操作)、DDL锁(对表结构进行操作)
- 使用方式: 乐观锁、悲观锁
- MyISAM与InnoDB关于锁方面的区别是什么
- MyISAM默认用的是表级锁, 不支持行级锁
- InnoDB默认用的是行级锁, 也支持表级锁
- 数据库事务的四大特性(ACID)
- 原子性(Atomic)
- 一致性(Consistency)
- 隔离性(Isolation)
- 持久性(Durability)
- 事务隔离级别以及各级别下的并发访问问题(
select @@tx_isolation;set session transaction isolation level read committed;)- 更新丢失: MySql所有事务隔离级别都在数据库层面上均可避免
- 脏读: READ-COMMITTED事务隔离级别以上可以避免
- 不可重复读: REPEATABLE-READ事务隔离级别以上可以避免
- 幻读: SERIALIZABLE事务隔离级别可以避免
- 隔离级别: 未提交读、已提交读、可重复读、串行化
- InnoDB可重复读隔离级别下如何避免幻读
- 当前读:
select …… lock in share mode;,select …… for update; - 当前读: update, delete, insert
- 快照读: 不加锁的非阻塞读, select
- 当前读:
- RC、RR级别下的InnoDB的非阻塞读(伪MVCC:多版本并发控制)如何实现
- 数据行内的
DB_TRX_ID、DB_ROLL_PTR、DB_ROW_ID字段 - undo日志: 通过
DB_TRX_ID控制前后顺序, 再通过DB_ROLL_PTR指向前一项修改
- 数据行内的
- 对主键索引或者唯一索引会用Gap锁吗
- 如果where条件全部命中, 则不会用Gap锁(间隙锁), 只会加记录锁
- 如果没有全部命中, 则会部分加上Gap锁

Redis
多路I/O复用模型
- 因地制宜
- 优先选择时间复杂度为O(1)的I/O多路复用函数作为底层实现(epoll/kqueue/evport)
- 以时间复杂度为O(n)的select作为保底
- 基于reactor设计模式监听I/O事件
- https://zhuanlan.zhihu.com/p/347779760
从海量Key里查询出某一固定前缀的Key
- 摸清数据规模, 即问清楚边界
- Keys pattern: 查找所有符合给定模式pattern的key
- Keys指令一次性返回所有匹配的key
- 键的数量过大会使服务卡顿
- Scan cursor [Match pattern] [Count count]
- 基于游标的迭代器, 需要基于上一次的游标延续之前的迭代过程
- 以0作为游标开始一次新的迭代, 直到命令返回游标0完成一次遍历
- 不保证每次执行都返回某个给定数量的元素, 支持模糊查询
- 一次返回的数量不可控, 只能是大概率符合count参数
如何通过Redis实现分布式锁
- Setnx key value: 如果key不存在, 则创建并赋值
- 时间复杂度: O(1)
- 返回值: 设置成功返回1; 设置失败返回0
- 会一直存在
- Expire key seconds
- 设置key的生存时间, 当key过期时(生存时间为0), 会被自动删除
- 缺点: 原子性不足
- Set key value [EX seconds] [PX milliseconds] [NX|XX]
- EX seconds: 设置键的过期时间为seconds秒
- PX millisecond: 设置键的过期时间为millisecond毫秒
- NX: 只有键不存在时, 才对键进行设置操作
- XX: 只有键已经存在时, 才对键进行设置操作
- Set操作成功完成后, 返回OK, 否则返回nil
- 如果有大量的key同时过期的注意事项
- 集中过期, 由于清除大量的key很耗时, 会出现短暂的卡顿现象
- 添加一定的随机值, 避免同时过期(缓存雪崩?)
如何使用Redis做异步队列
- 可以使用List作为队列, RPush生产消息, LPop消费消息
- 缺点: 没有等待队列里有值就直接消费
- 弥补: 可以通过在应用层引入Sleep机制去调用LPop重试
- BLPop key [key…] timeout
- 阻塞直到队列有消息或者超时
- 只能供一个消费者消费
- pub/sub: 主题订阅者模式
- 发送者(pub)发送消息, 订阅者(sub)接受消息
- 订阅者可以订阅任意数量的频道
- 消息的发布时无状态的, 无法保证可达
- 语法
- subscribe myTopic
- public myTopic "something"
Redis持久化
- RDB(快照)持久化: 保存某个时间点的全量数据快照
- stop-writes-on-bgsave-error 在备份出错时停止写入
- rdbcompression 备份时压缩(建议设置为no)
- SAVE: 阻塞Redis的服务器进程, 直到RDB文件被创建完成(不常用)
- BGSAVE: Fork出一个子进程来创建RDB, 不阻塞服务器进程
- 自动保存
- 根据redis.conf配置里的SAVE m n 定时触发(用的是BGSAVE)
- 主从复制时, 主节点自动触发
- 执行Debug Reload
- 执行Shutdown且没有开启AOF持久化
- 缺点
- 内存数据的全量同步, 数据量大会由于I/O而严重影响性能
- 可能会因为Redis挂掉而丢失从当前到最近一次快照期间的数据
- AOF(Append-Only-File)持久化: 保持写状态
- 记录下除了查询意外的所有变更数据库状态的指令
- 以append的形式最佳保存到AOF文件中(增量)
- appendonly yes 开启AOF
- appendfsync
- always: 只要发生了变化就同步
- everysec: 每隔一秒同步
- no: 将写入时机交给系统, 一般是写满缓存区
- 日志重写解决AOF文件大小不断增大的问题
- 调用fork(), 创建一个子进程
- 子进程把新的AOF写到一个临时文件里, 不依赖原来的AOF文件
- 主进程持续将新的变动同时写到内存和原来的AOF里
- 主进程获取子进程重写AOF的完成信号, 往新AOF同步增量变动
- 使用新的AOF文件替换掉旧的AOF文件
- 文件体积大, 恢复时间长
- RDB-AOF混合持久化方式
- BGSAVE做镜像全量持久化, AOF做增量持久化
使用Pipeline
- Pipeline和Linux的管道类似
- Redis基于请求/响应模型, 单个请求处理需要一一应答
- Pipeline批量执行指令, 节省多次IO往返的时间
- 有顺序依赖的指令建议分批发送
- 主从同步(缺乏高可用性)
- 全同步
- Slave发送sync命令到Master
- Master启动一个后台进程, 将Redis中的数据快照保存到文件中
- Master将保存数据快照期间接受到的写命令缓存起来
- Master完成写文件操作后, 将该文件发送给Slave
- 使用新的RDB文件替换掉旧的RDB文件
- Master将这期间收集到的增量写命令发给Slave端
- 增量同步过程
- Master接受到用户的操作指令, 判断是否需要传播到Slave
- 将操作记录追加到AOF文件
- 将操作传播到其他Slave
- 对齐主从库
- 往响应缓存写入指令
- 将缓存中的数据发送给Slave
- 全同步
- Redis Sentinel(哨兵模式)
- 解决主从同步Master宕机后的主从切换问题
- 监控: 检查主从服务器是否运行正常
- 提醒: 通过API向管理员或者其他应用程序发送故障通知
- 自动故障迁移: 主从切换
- 流言协议Gossip
- 每个节点都随机地与对方通信, 最终所有节点的状态达成一致
- 种子节点定期随机向其他节点发送节点列表以及需要传播的消息
- 不保证信息一定会传递给所有节点, 但是最终会趋于一致
- 解决主从同步Master宕机后的主从切换问题
Redis的集群原理
- 如何从海量数据里快速找到所需
- 分片: 按照某种规则去划分数据, 分散存储在多个节点上
- 常规的按照哈希划分无法实现节点的动态增减, 导致大量key无法被命中
- 一致性哈希算法
- 对2^32取膜, 将哈希值空间组织成虚拟的圆环
- 对服务器取哈希, 定位其在哈希环上的位置
- 将数据key使用相同的函数计算出哈希值, 放入到相应服务器(顺时针放入)
- 哈希环倾斜问题: 引入虚拟节点, 对每个服务器计算多个哈希值(增加后缀编号)
Linux
体系结构
- 主要分为用户态和内核态
- 内核: 本质是一段管理计算机硬件设备的程序
- 系统调用: 内核的访问接口, 是一种不能再简化的操作
- 公用函数库: 系统调用的组合拳
- Shell: 命令解释器, 可编程
使用技巧
- 在指定目录下查找文件: find path [option] params
-name根据名字target*匹配模式-iname模糊搜索
- 检索文件内容: grep [option] pattern file
- 全称: Global Regular Expression Print
- 查找文件里符合条件的字符串
- 对文件内容做统计
- awk [option] ‘cmd’ file
- 一次读取一行文本, 按输入分隔符进行切片, 切成多个组成部分
- 将切片直接保存在内建的变量中, $1, $2……($0表示行的全部)
- 支持对单个切片的判断, 支持循环判断, 默认分隔符为空格
- 批量替换文本内容
- sed [option] 'sed command' filename
- 全名stream editor, 流编辑器
- 适合用于对文本的行内容进行处理
JVM
JVM如何加载class文件
- Class Loader: 依据特定格式, 加载class文件到内存
- Runtime Data Area: JVM内存结构模型空间
- Execution Engine: 对命令进行解析
- Native Interface: 融合不同开发语言的原生库为Java所用
什么是反射
Java反射机制是在运行状态中, 对于任意一个类, 都能知道这个类的所有属性和方法; 对于任意一个对象, 都能调用它的任意方法和属性; 这种动态获取信息以及动态调用对象方法的功能称为Java语言的反射机制
反射实例
Javapublic class Robot { private String name; public void sayHi(String helloSentence) { System.out.println(helloSentence + " " + name); } private String throwHello(String tag) { return "Hello" + tag; } } public class ReflectSample { public static void main(String[] args) throws Exception{ Class rc = Class.forname("package.name"); Robot r = (Robot) rc.newInstance(); System.out.println("Class name is " + rc.getName()); Method getHello = rc.getDeclaredMethod("throwHello", String.class); getHello.setAccessible(true); Object str = getHello.invoke(r, "Bob"); System.out.println("result: " + str); Method sayHi = rc.getMethod("syaHi", String.class); Field name = rc.getDeclaredField("name"); name.setAccessible(true); name.set(r, "Alice"); sayHi.invoke(r, "welcome"); } }
ClassLoader
ClassLoader在Java中有着非常重要的作用, 它主要工作在Class装在的加载阶段, 其主要作用是从系统外部获得Class二进制数据流. 他是Java的核心组件, 所有的Class都是由ClassLoader进行加载的, ClassLoader负责通过将Class文件里的二进制数据流装载进系统, 然后交给Java虚拟机进行连接、初始化等操作.
BootStrap ClassLoader: C++编写, 加载核心库java.*
Extension ClassLoader: Java编写, 加载扩展库javax.*
App ClassLoader: Java编写, 加载程序所在目录
Custom ClassLoader: Java编写, 定制化加载
关键函数
Javaprotected Class<?> findClass(String name) throws ClassNotFoundException{ throw new ClassNotFoundException(name); } protected final Class<?> defineClass(byte[] b, int off, int len) throw ClassFormatError { return defineClass(null, b, off, len, null); }自定义
Javapublic class Wali{ static{ System.out.println("Hello World"); } }Javapublic class MyClassLoader extends ClassLoader { private String path; private String classLoaderName; public MyClassLoader(String path, String classLoaderName) { this.path = path; this.classLoaderName = classLoaderName; } //用于寻找类文件 @Override public Class findClass(String name) { byte[] b = loadClassData(name); return defineClass(name, b, 0 , b.length); } //用于加载类文件 private byte[] loadClassData(String name) { name = path + name + ".class"; InputStream in = null; ByteArrayOutputStream out = null; try { in = new FileInputStream(new File(name)); out = new ByteArrayOutputStream(); int i = 0; while((i = in.read()) != -1) { out.write(i); } } catch (Exception e) { e.printStackTrace(); } finally { try { out.close(); in.close(); } catch (Exception e) { e.printStackTrace(); } } return out.toByteArray(); } } public class ClassLoaderChecker { public static void main(String[] args) throws Exception { MyClassLoader m = new MyClassLoader("/PATH", "myClassLoader"); Class c = m.loadClass("Wali"); System.out.println(c.getClassLoader()); c.newInstance(); } }
双亲委派机制
- 自底向上检查类是否已经加载, 自顶向下尝试加载类
- 所谓的双亲并不是有"双", 而是指代源码中的parent字段, 而parent值得就是上一层的加载类
- 为什么要使用双亲委派机制去加载: 避免多份同样字节码的加载
类的加载方式
- 隐式加载: new
- 显式加载: classLoader(不执行static, 应用于Spring IOC的懒加载等), forName(会执行static)等(需要调用newInstance, 且不支持调用有参构造)
类的加载过程:
- 加载: 通过ClassLoader加载class文件字节码, 生成Class对象
- 链接:
- 校验: 检查加载的class的正确性和安全性(格式等)
- 准备: 为类变量分配存储空间并设置类变量(static)初始值
- 解析: JVM将常量池内的符号引用转换为直接引用
- 初始化: 执行类变量赋值和静态代码块
JAVA内存模型
地址空间的划分
- 内核空间
- 用户空间
JVM内存模型
- 线程私有: 程序计数器、虚拟机栈、本地方法栈
- 线程共享: MetaSpace、Java堆
- 程序计数器(Program Counter Register)
- 当前线程所执行的字节码行号指示器(逻辑计数器)
- 改变计数器的值来选取下一条需要执行的字节码指令
- 和线程是一对一的关系, 即"线程私有"
- 对Java方法是正在执行的虚拟机方法计数, 对Native方法则计数器值为Undefined
- 不会发生内存泄露
- Java虚拟机栈(Stack)
- Java方法执行的内存模型
- 包含多个栈帧
- 每个栈帧都包含:
- JVM指令
- 局部变量表: 包含方法执行过程中的所有变量
- 操作数栈: 入栈、出栈、复制、交换、产生消费变量, 类似于原生CPU寄存器
- 递归为什么会引发java.lang.StackOverflowError: 每一次调用都会生成新的栈帧, 同时旧的栈帧不会被移除, 所以就会溢出
- 虚拟机栈过多还会引发java.lang.OutOfMemoryError异常
- 动态链接
- 方法返回地址等
- 本地方法栈: 与虚拟机栈相似, 主要作用于标注了native的方法
- 元空间(MetaSpace)与永久代(PermGen)的区别
- 都是用来class相关信息, 都是方法区的实现
- 元空间使用本地内存, 而永久代使用的是jvm的内存
- MetaSpace相比PermGen的优势
- 字符串常量存在永久代中, 容易出现性能问题和内存溢出
- 类和方法的信息大小难以确定, 给永久代的大小指定带来困难
- 永久代会为GC带来不必要的复杂性
- 方便HotSpot与其他JVM如Jrockit的集成
- Java堆(Heep)
- 对象实例的分配区域
- GC管理的主要区域
相关问题
JVM三大性能调优参数的含义
- -Xss: 规定了每个线程虚拟机栈(堆栈)的大小
- -Xms: 堆的初始值
- -Xmx: 堆能达到的最大值
Java内存模型中堆和栈的区别——内存分配策略
- 静态存储: 编译时确定每个数据目标在运行时的存储空间需求
- 栈式存储: 数据区需求在编译时未知, 运行时模块入口前确定
- 堆式存储: 编译时或运行时模块入口都无法确定, 动态分配
- 联系: 引用对象、数组时, 栈里定义变量保存堆中目标的首地址
- 管理方式: 栈自动释放, 堆需要GC
- 空间大小: 栈比堆小
- 碎片相关: 栈产生的碎片远小于堆
- 分配方式: 栈支持静态和动态分配, 而堆仅支持动态分配
- 效率: 栈的效率比堆高
元空间、堆、线程独占部分间的联系——内存角度
Javapublic class HelloWorld { private String name; public void sayHello() { System.out.println("Hello " + name); } public void setName(String name) { this.name = name; } public static void main(String[] args) { int a = 1; HelloWorld hw = new HelloWorld(); hw.setName("test"); hw.sayHello(); } }元空间:
- Class: HelloWorld - Method:……\main - Field: name
- Class: System
Java堆
- Object: String("test")
- Object: HelloWorld
线程独占
- Parameter reference: "test" to String object
- Variable reference: "hw" to HelloWorld object
- Local Variables: a with 1, lineNo
Java垃圾回收机制
判定对象是否为垃圾的算法
- 引用计数算法
- 通过判断对象的引用数量来决定对象是否可以被回收
- 每个对象实例都有一个引用计数器, 被引用则+1, 完成引用则-1
- 任何引用计数为0的对象实例可以被当作垃圾回收
- 缺点: 无法检测出循环引用的情况导致内存泄漏
- 可达性分析算法
- 通过判断对象的引用链是否可达来决定对象是否可以被回收
- 可作为GC Root的对象
- 虚拟机栈中引用的对象(栈帧中的本地变量表)
- 方法区中的常量引用的对象
- 方法区中的类静态属性引用的对象
- 本地方法栈中JNI(Native方法)的引用对象
- 活跃线程的引用对象
垃圾回收算法
- 标记-清除算法(Mark and Sweep)
- 标记: 从根集合进行扫描, 对存活的对象进行标记
- 清除: 对堆内存从头到尾进行线性遍历, 回收不可达对象内存
- 复制算法(Copying)
- 分为对象面和空闲面, 对象在对象面上创建
- 存活的对象从对象面复制到空闲面
- 将对象面所有对象内存清理
- 解决了碎片化问题, 顺序分配内存, 简单高效, 适用于对象存活率低的场景
- 标记-整理算法(Compacting)
- 标记: 从根集合进行扫描, 对存活的对象进行标记
- 清除: 移动所有存活的对象, 且按照内存地址依次序依次排列, 然后将末端内存地址以后的内存全部回收
- 相对耗时
- 避免内存的不连续行
- 不用设置两块内存互换
- 适用于存活率高的场景
- JVM的运行模式
- Server: 启动较慢, 但是稳定后运行速度比Client快
- Client: 启动较快
- 分代收集算法(Generational Collector)
- 垃圾回收算法的组合拳
- 按照对象生命周期的不同划分区域以采用不同的垃圾回收算法
- 目的: 提高JVM的回收效率
- JDK8及其以后的版本没有没永久代了, 只有年轻代和老年代
- GC的分类
- Minor GC
- Full GC
- 年轻代: 尽可能快速地收集掉那些生命周期短的对象
- 复制算法, Minor GC
- Eden区: 被创建的对象最优先放在Eden区, 但是也不绝对
- 两个Surivivor区: 循环接受Eden和另一个Surrivivor区的存活对象, 并且寿命+1, 寿命上限由-XX:MaxTenuringThreshold决定, 通常为15
- 经历一定Minor次数依然存活或者Survivor区中放不下的对象, 会被放到老年代
- 常用的调优参数
- -XX:SurvivorRatio: Eden和Survivor的比值, 默认8:1
- -XX:NewRatio: 老年代和年轻代内存大小的比例
- -XX:MaxTenuringThreshold: 对象从年轻代晋升到老年代经过GC次数的最大阈值
- 垃圾收集器: (-XX:UseAdaptiveSivePolicy: 虚拟机自动调优)
- Serial收集器(-XX:+UseSerialGC, 复制算法)
- 单线程收集, 进行垃圾收集时, 必须暂停所有工作线程
- 简单高效, Client模式下默认的年轻代收集器
- ParNew收集器(-XX:+UseParNewGC, 复制算法)
- 多线程收集, 其余的行为、特点和Serial收集器一样
- 单核执行效率不如Serial, 在多核下执行才有优势
- Parallel Scavenge收集器(-XX:+UseParallelGC, 复制算法)
- 吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)
- 比起关注用户线程停顿时间, 更关注系统的吞吐量
- 在多核下执行才有优势, Server模式下默认的年轻代收集器
- Serial收集器(-XX:+UseSerialGC, 复制算法)
- 老年代: 存放生命周期较长的对象
- 标记-清理算法、标记整理算法, Full GC、Major GC
- Full GC比Minor GC慢, 但执行频率低
- 触发Full GC的条件
- 老年代空间不足
- 永久代空间不足(JDK1.7之前)
- CMS GC时出现promotion failed, concurrent mode failure
- promotion failed: survivor区放不下想要放到老年代区域时, 发现老年代区域也放不下了, 则会触发该警告
- concurrent mode failure: CMS GC的同时有对象要放入老年代中, 而此时老年代空间不足, 则会触发该警告
- Minor GC晋升到老年代的平均大小大于老年代的剩余空间
- 调用System.gc()
- 使用RMI来进行RPC或管理JDK应用, 每小时执行一次Full GC
- 垃圾收集器:
- Serial Old收集器(-XX:UseSerialOldGC, 标记-整理算法)
- 单线程收集, 进行垃圾收集时, 必须暂停所有工作线程
- 简单高效, Client模式下默认的老年代收集器
- Parallel Old收集器(-XX:+UseParallelOldGC, 标记-整理算法)
- 多线程, 吞吐量优先
- CMS收集器(-XX:+UseConcMarkSweepGC, 标记-清除算法)
- 初始化标记: stop-the-world
- 并发标记: 并发追溯标记, 程序不会停顿
- 并发预清理: 查找执行并发标记阶段从年轻代晋升到老年代的对象
- 重新标记: 暂停虚拟机, 扫描CMS堆中的剩余对象
- 并发清理: 清理垃圾对象, 程序不会停顿
- 并发重制: 重制CMS收集器的数据结构
- G1收集器(-XX:+UseG1GC, 复制+标记-整理算法)
- 并行和并发
- 分代收集
- 空间整合
- 可预测的停顿
- 将整个Java堆内存划分成多个大小相等的Region, 年轻代和老年代不再物理隔离
- JDK11: Epsilon GC和ZGC
- Serial Old收集器(-XX:UseSerialOldGC, 标记-整理算法)
面试题合集
Object的finalize()方法的作用是否与C++的析构函数作用相同
- 与C++的析构函数不同, 析构函数调用确定, 而它的是不确定的
- 将未被引用的对象放置于F-Queue队列
- 方法执行随时可能会被终止
- 给予对象最后一次重生的机会
- 代价高昂, 不确定性强, 不建议使用
Java中的强引用、软引用、弱引用、虚引用有什么用
强引用(Strong Reference)
- 最普遍的引用: Object obj = new Object();
- 抛出OutOfMemoryError终止程序也不会回收具有强引用的对象
- 通过将对象设置为null来弱化引用, 使其被回收
软引用(Soft Reference)
对象处在游泳但非必须的状态
只有当内存空间不足时, GC会回收该引用的对象的内存
可以用来实现高速缓存
JavaString str = new String("adc"); // 强引用 SoftReference<String> softRef = new SoftReference<String>(str); // 软引用
弱引用(Weak Reference)
非必须的对象, 比软引用更弱一些
GC时会被回收
被回收的概率也不大, 因为GC线程的优先级比较低
适用于引用偶尔被使用且不影响垃圾回收的对象
JavaString str = new String("adc"); // 强引用 WeakReference<String> weakRef = new WeakReference<String>(str); // 弱引用
虚引用(Phantom Reference)
不会决定对象的生命周期
任何时候都可能被垃圾收集器回收
跟踪对象被垃圾收集器回收的活动, 起哨兵作用
必须和引用队列Reference Queue联合使用
javaString str = new String("adc"); // 强引用 ReferenceQueue queue = new ReferenceQueue(); PhantomReference<String> ref = new PhantomReference(str, queue); // 虚引用
引用队列(Reference Queue)
- 无实际存储结构, 存储逻辑依赖于内部节点之间的关系来表达, 类似于链表的结构
- 储存关联的且被GC的软引用、弱引用或者虚引用
线程
进程与线程
由来
- 串行: 初期的计算机串行执行任务, 并且需要长时间等待用户输入
- 批处理: 预先将用户的指令集中成清单, 批量串行处理用户指令, 仍然无法并行执行
- 进程: 进程独占内存空间, 保存各自运行状态, 互相间不干扰且可以互相切换, 为并发处理任务提供了可能
- 线程: 共享进程的内存资源, 互相间切换更快速, 支持更细粒度的任务控制, 使进程内的子任务得以并发执行
进程时资源分配的最小单位, 线程时CPU调度的最小单位
- 所有与进程有关的资源, 都被记录在PCB中
- 进程时抢占处理机的调度单位, 线程属于某个进程, 共享其资源
- 线程只由堆栈寄存器、程序计数器和TCB组成
区别
- 线程不能看作独立应用, 而进程可以
- 进程有独立的地址空间, 互相不影响, 线程只是进程的不同执行路径
- 线程没有独立的地址空间, 多进程的程序比多线程程序健壮
- 进程的切换比线程的切换开销大
Java进程和线程的关系
- Java对操作系统提供的功能进行封装, 包括进程和线程
- 运行一个程序会产生一个进程, 进程包含至少一个线程
- 每个进程对应一个JVM实例, 多个线程共享JVM里的堆
- Java采用单线程编程模型, 程序会自动创建主线程
- 主线程可以创建子线程, 原则上要后于子线程完成执行
常见问题
Thread中的start和run方法的区别
- start方法会去调用JVM_StartThread方法, 创建新的线程, 然后调用Thread的run()方法
- run()方法只是Thread的一个普通方法的调用
Thread和Runnable时什么关系
- Thread时实现了Runnable接口的类, 使得run支持多线程
- 因类的单一继承原则, 推荐多使用Runnable接口
如何给run()方法传参
- 构造函数传参
- 成员变量传参
- 回调函数传参
如何实现处理线程的返回值
主线程等待法
javapublic class CycleWait implements Runnable{ private String value; public void run() { try { Thread.currentThread().sleep(5000); } catch (InterruptedException e) { e.printStackTrace(); } value = "we have data now"; } public static void main(String[] args) { CycleWait cw = new CycleWait(); Thread t = new Thread(cw); t.start(); while (cw.value == null) { Thread.currentThread().sleep(100); // 主线程等待 } System.out.println("value" + cw.value); } }使用Thread类的join()阻塞当前线程以等待子线程处理完毕
- 粒度过粗, 无法在线程内精细控制
通过Callable接口实现: 通过FutureTask或者线程池获取
javapublic class MyCallable implements Callable<String> { @Override public String call() throws Exception{ String value = "test"; System.out.println("Ready to work"); Thread.currentThread().slepp(5000); System.out.println("task done"); return value; } } public class FutureTaskDemo { public static void main(String[] args) { FutureTask<String> task = new FutureTask<String>(new MyCallable()); new Thread(task).start(); if (!task.isDone()) { System.out.println("task has not finished, please wait!"); } System.out.println("task return: " + task.get()); } }javapublic class ThreadPoolDemo { public static void main(String[] args) { ExecutorService newCachedThreadPool = Executors.newCachedThreadPool(); Future<String> future = newCachedThreadPool.submit(new MyCallable()); if (!future.isDone()) { System.out.println("task has not finished, please wait!"); } try { System.out.println(future.get()); } catch (InterruptedException e) { e.printStackTrace(); } catch (ExecutionException e) { e.printStackTrace(); } finally { newCachedThreadPool.shutdown(); } } }
线程的状态
- 新建(new): 创建后尚未启动的线程的状态
- 运行(Runnable): 包含Running和Ready
- 无限期等待(Waiting): 不会被分配CPU执行时间, 需要显式被唤醒
- 没有设置Timeout参数的Object.wait()方法
- 没有设置Timeout参数的Thread.join()方法
- LockSupport.park()方法
- 限期等待(Timed Waiting): 在一定时间后会由系统自动唤醒
- Thread.sleep()方法
- 设置了Timeout参数的Object.wait()方法
- 设置了Timeout参数的Thread.join()方法
- LockSupport.parkNanos()方法
- LockSupport.parkUntil()方法
- 阻塞(Blocked): 等待获取排它锁
- 结束状态(Terminated): 已终止线程的状态, 线程已经结束执行
sleep和wait的区别
- sleep时Thread类的方法, wait是Object类中定义的方法
- sleep()方法可以在任何地方使用
- wait()方法只能在synchronized方法或synchronized块中使用
- Thread.sleep只会让出CPU, 不会导致锁行为的改变
- Object.wait不仅会让出CPU, 还会释放已经占有的同步资源锁
notify()和notifyAll()的区别
锁池EntryList
假设线程A已经拥有了某个对象(不是类)的锁, 而其他线程B、C想要调用这个对象的某个synchronized方法(或者块), 由于B、C线程在进入对象的synchronized(或者块)之前必须先获得该对象锁的拥有权, 而恰巧该对象的锁目前正被线程A所占用, 此时B、C线程就会被阻塞, 进入一个地方去等待锁的释放, 这个地方便是该对象的锁池
等待池WaitSet
假设线程A调用了某个对象的wait()方法, 线程A就会释放该对象的锁, 同时线程A就进入到了该对象的等待池中, 进入到等待池中的线程不会去竞争的锁
notifyAll会让所有处于等待池的线程全部进入锁池去竞争获取锁的机会
notify只会随机选取一个处于等待池中的线程进入锁池去竞争获取锁的机会
yield
- 当调用Thread.yield()函数时, 会给线程调度器一个当前线程愿意让出CPU使用的暗示, 但是线程调度器可能会忽略这个暗示
interrupt
- 调用interrupt(), 通知线程应该中断了
- 如果线程处于被阻塞状态, 那么线程将立即退出被阻塞状态, 并抛出一个InterruptedException异常
- 如果线程处于正常状态, 那么会将该线程的中断标志设置为true, 被设置中断标志的线程将继续正常运行, 不受影响
- 需要被调用的线程配合中断
- 在正常运行任务时, 经常检查本线程的中断标志位, 如果被设置了中断标志就自行停止线程
- 如果线程处于正常活动状态, 那么会将该线程的中断标志设置为true, 被设置中断标志的线程将继续正常运行, 不受影响
- 调用interrupt(), 通知线程应该中断了
Synchronized
底层原理
- 对象头
虚拟机位数 头对象结构 说明 32/64 bit Mark Word 默认存储对象的hashCode, 分代年龄, 锁类型, 锁标志位等信息 32/64 bit Class Metadata Address 类型指针指向对象的类元数据, JVM通过这个指针确定该对象是哪个类的数据 - Monitor: 每个Java对象天生自带了一把看不见的锁
锁消除
- JIT编译时, 堆运行上下文进行扫描, 去除不可能存在竞争的锁
锁粗化
- 防止反复加锁去锁, 扩大锁的范围
synchronized的四种状态
无锁
偏向锁
- 减少同一线程获取锁的代价
- 大多数情况下, 锁不存在多线程竞争, 总是由同一线程多次获取
如果一个线程获得了锁, 那么锁就进入偏向模式, 此时Mark Word的结构也变为了偏向锁结构, 当该线程再次请求锁时, 无需再做任何同步操作, 即获取锁的过程只需要检查Mark Word的锁标记位为偏向锁以及当前线程ID等于Mark Word的ThreadID即可, 这样就省去了大量有关锁申请的操作
轻量级锁
- 轻量级锁是由偏向锁升级来的, 偏向锁运行在一个线程进入同步块的情况下, 当第二个线程加入锁争用的时候, 偏向锁就会升级为轻量级锁
- 适用场景: 线程交替执行同步块
重量级锁
- 线程竞争不断自旋, 不消耗CPU
- 线程阻塞, 响应时间缓慢, 在多线程下, 平凡的获取释放锁, 会带来巨大的性能消耗
解锁
- 锁的内存语义
- 当线程释放锁时, Java内存模型会把该线程对应的本地内存中的共享变量刷新到主内存中
- 而当线程获取锁时, Java内存模型会把该线程对应的本地内存置为无效, 从而使得被监视器保护的临界区代码必须从主内存中读取共享变量
synchronized和ReentrantLock的区别
- ReentrantLock(重入锁)
- 位于java.util.concurrent.lcoks包
- 和CountDownLatch、FutureTask、Semaphore一样基于AQS实现
- 能够实现比synchronized更细的粒度控制, 如控制fairness
ReentrantLock fairLock = new ReentrantLock(true);- 参数为true时, 倾向于将锁赋予等待时间最久的线程
- 公平锁: 获取锁的顺序按先后调用lock方法的顺序(慎用)
- 非公平锁: 抢占的顺序不一定, 看运气
- synchronized是非公平锁
- 调用lock()之后, 必须调用unlock()释放锁
- 性能未必比synchronized高, 并且也是可重入的
- ReentrantLock将锁对象化
- 判断是否有线程, 或者某个特定线程, 在排队等待获取锁
- 带超时的获取锁的尝试
- 感知有没有成功
- 将wait\notify\notifyAll对象化
- java.util.concurrent.locks.Condition
- 总结
- synchronized是关键字, RentrantLock是类
- ReentrantLock可以对获取锁的等待时间进行设置, 避免死锁
- ReentrantLock可以获取各种锁的信息
- ReentrantLock可以灵活地实现多路通知
- sync操作Mark Word, lock调用Unsafe类的park()方法
- ReentrantLock(重入锁)
线程池
Executor接口
Executor: 运行新任务的简单接口, 将任务提交和任务执行细节解藕
ExecutorService: 具备管理执行器和任务生命周期的方法, 提交任务机制更完善
ThreadPoolExecutor:
corePoolSize: 核心线程数量
maximumPoolSize: 线程不够用时能够创建的最大线程数
workQueue: 任务等待队列
keepAliveTime: 空闲线程存在时长
threadFactory: 创建新线程, Executors.defaultThreadFactory()
handler: 线程池的饱和策略
- AbortPolicy: 抛出异常
- CallerRunsPolicy: 用调用者所在的线程来执行任务
- DiscardOldestPolicy: 丢弃队列中最靠前的任务, 并执行当前任务
- DiscardPolicy: 直接丢弃任务
如果运行的线程少于corePoolSize, 则创建新线程来处理任务, 即使线程池中的其他线程是空闲的;
如果线程池中的线程数量大于等于corePoolSize且小于maximumPoolSize, 则只有当workQueue满时菜创建新的线程去处理任务;
如果设置的corePoolSize和maximumPoolSize相同, 则创建的线程池的大小是固定的, 这时如果有新任务提交, 若workQueue未满, 则将请求放入workQueue中, 等待有空闲的线程去workQueue中取任务并处理;
如果运行的线程数量大于等于maximumPoolSize, 这时如果workQueue已经满了, 则通过handler所指定的策略来处理任务;
线程池的状态
- RUNNING: 能接受新提交的任务, 并且也能处理阻塞队列中的任务
- SHUTDOWN: 不接受新提交的任务, 但可以处理存量任务
- STOP: 不接受新的任务, 也不处理存量任务
- TIDYING: 所有的任务都已终止
- TERMINATED: terminated()方法执行完后进入该状态
线程池的大小如何选定
- CPU密集型: 线程数=核心数+1
- I/O密集型: 线程数=核心数*(1 + 平均等待时间/平均工作时间)
Java常用类
Java异常体系
- Error和Exception的区别
- 都继承于Throwable
- Error: 系统无法处理的系统错误, 编译器不做检查
- Exception: 程序可以处理的异常, 捕获后可能恢复
- RuntimeException: 不可预知的, 程序应当自行避免
- 非RuntimeException: 可预知的, 从编译器校验的异常
- 从责任角度
- Error属于JVM需要负担的责任
- RuntimeException是程序应该负担的责任
- Checked Exception可检查异常是Java编译器应负担的责任
- 总结: 前者是程序无法处理的错误, 后者是可以处理的错误
- 常见Error以及Exception
- RuntimeException
- NullPointerException -空指针异常
- ClassCastException -类型强制转换异常
- IllegalArgumentException -传递非法参数异常
- IndexOutOfBoundsException -下标越界异常
- NumberFormatException -数字格式异常
- 非RuntimeException
- ClassNotFoundException -找不到指定class的异常
- IOException -IO操作异常
- Error
- NoClassDefFoundError -找不到class定义的异常
- 类依赖的class或者jar不存在
- 类文件存在, 但是存在不同的域中
- 大小写问题, javac编译的时候是无视大小写的, 很有可能编译出来的class文件就与想要的不一样
- StackOverflowError -深递归导致栈被耗尽而抛出的异常
- OutOfMemoryError -内存溢出异常
- NoClassDefFoundError -找不到class定义的异常
- 异常处理机制
- 抛出异常: 创建异常对象, 交由运行时系统处理
- 捕获异常: 寻找合适的异常处理器处理异常, 否则终止运行
- 延迟捕获: 异常的捕获和处理应尽可能延迟, 让掌握更多信息的作用域来处理异常
- 高效主流的异常处理框架
- 设计一个通用的继承自RuntimeException的异常来统一处理
- 其余异常都统一转译为上述异常AppException
- 在catch之后, 抛出上述异常的子类, 并提供足以定位的信息
- 由前端接收AppException做统一处理
- try-catch的性能
- try-catch块影响JVM的优化
- 异常对象实例需要保存栈快照等信息, 开销较大
- RuntimeException
Java集合框架
Collection
- List
- 底层是数组, 查询快, 增删慢
- ArrayList: 线程不安全, 效率高
- Vector: 线程安全, 效率低
- 底层是链表, 查询慢, 增删快
- LinkedList: 线程不安全, 效率高
- 底层是数组, 查询快, 增删慢
- Set
- 底层是哈希表
- HashSet: 保证元素唯一性
- 底层是二叉树
- TreeSet: 保证元素排序
- 自然排序, 让对象所属的类去实现comparable接口, 无参构造
- 比较器接口comparator, 带参构造
- TreeSet: 保证元素排序
- 底层是哈希表
- Map
- HashMap
- put方法的逻辑
- 若HashMap未被初始化, 这进行初始化操作
- 对Key求Hash值, 依据Hash值计算下标
- 若未发生碰撞, 则直接放入桶中
- 若发生碰撞, 则以链表的方式链接到后面
- 若链表长度超过阈值, 且HashMap元素超过最低树化容量, 则将链表转成红黑树
- 若节点已经存在, 则用新值替换旧值
- 若桶满了(默认容量16*扩容因子0.75), 就需要resize(扩容2倍后重排)
- 如何减少碰撞
- 扰动函数: 促使元素位置分布均匀, 减少碰撞几率
- 使用final对象, 并采用合适的equals()和hashCode()方法
- put方法的逻辑
- Hashtable
- 早期Java类库提供的哈希表的实现
- 线程安全: 涉及到修改Hashtable的方法, 使用synchronized修饰
- 串行化的方式运行, 性能较差
- ConcurrentHashMap
- CAS+synchronized使锁更细化
- 比起Segment, 锁拆得更细
- 首先使用无锁操作CAS插入头节点, 失败则循环重试
- 若头节点已存在, 则尝试获取头节点的同步锁, 再进行操作
- size()方法和mappingCount()方法的异同, 两者计算是否准确
- 多线程环境下如何扩容
- 三者的区别
- HashMap线程不安全, 数组+链表+红黑树
- Hashtable线程安全, 锁住整个对象, 数组+链表
- ConcurrentHashMap线程安全, CAS+同步锁, 数组+链表+红黑树
- HashMap的key、value均可以为null, 其他两个则不可以
- HashMap
JUC知识点梳理
- CountDownLatch: 让主线程等待一组事件发生后继续执行, 事件指的是CountDownLatch里的countDown()方法
- CyclicBarrier: 阻塞当前线程, 等待其他线程
- 等待其他线程, 且会阻塞自己当前线程, 所有线程必须同时到达栅栏位置后, 才能继续执行
- 所有线程到达栅栏处, 可以触发执行另一个预先设置的线程
- Semaphore: 控制某个资源可被同时访问的线程个数
- Exchanger: 两个线程到达同步点后, 互相交换数据
- BlockingQueue: 提供可阻塞的入队和出队操作
- ArrayBlockingQueue: 一个由数组结构组成的有界阻塞队列
- LinkedBlockingQueue: 一个由链表结构组成的有界/无界阻塞队列
- PriorityBlockingQueue: 一个支持优先级排序的无界阻塞队列
- DealyQueue: 一个使用优先级队列实现的无界阻塞队列
- SynchronousQueue: 一个不存储元素的阻塞队列
- LinkedTranserQueue: 一个由链表结构组成的无界阻塞队列
- LinkedBlockingDeque: 一个由链表结构组成的双向阻塞队列
IO操作
- Block-IO: InputStream和OutputStream, Reader和Writer
- NonBlock-IO: 构建多路复用、同步非堵塞的IO操作(轮询)
- NIO:
- Channels
- FileChannel:
- transferTo: 把FileChannel中的数据拷贝到另一个Channel
- transferFrom: 把另一个Channel中的数据拷贝到FileChannel
- 避免了两次用户态和内核态间的上下文切换, 即“零拷贝”, 效率较高
- DatagramChannel
- SocketChannel
- ServerSocketChannel
- FileChannel:
- Buffers
- ByteBuffer(Char、Double、Float、Int、Long、Short)
- MappedByteBuffer
- Selectors
- 最大连接数
- select: 单个进程所能打开的最大链接数由FD_SETSIZE宏定义, 其大小是32个整数的大小(在32位的机器上, 大小是32*32, 64位机器上FD_SETSIZE为32*64), 我们可以对其进行修改, 然后重新编译内核, 但是性能无法保证, 需要做进一步测试
- poll: 本质上select没有区别, 但是它没有最大链接数的限制, 原因是它是基于链表来存储的
- epoll: 虽然连接数有上限, 但是很大, 1G内存的机器上可以开10万左右的连接
- FD(文件句柄)剧增带来的IO效率问题
- select: 因为每次调用时都会对连接进行线性遍历, 所以睡着FD的增加会造成便利速度的线性下降
- poll: 同上
- epoll: 由于epoll是根据每个FD上的callback函数来实现的, 只有活跃的socket才会主动调用callback, 所以在活跃socket较少的情况下, 使用epoll不会有线性下降的问题, 但是所有socket都很活跃的情况下, 可能会有性能问题
- 消息传递方式
- select: 内核需要将消息传递到用户空间, 需要内核的拷贝动作
- poll: 同上
- epoll: 通过内核和用户空间共享一块内存来实现, 性能较高
- 最大连接数
- Channels
- Asynchronous IO: 基于事件和回调机制
- 基于回调: 实现CompletionHandler接口, 调用时触发回调函数
- 返回Future: 通过isDone()查看是否准备好, 通过get()等待返回数据
Spring
IOC
- 实现方式
- Setter
- Interface
- Constructor
- Annotation
- 流程
- 读取Bean配置信息, 生成注册表(利用反射)
- XML
- @Coniguration
- @Autowired
- 根据Bean注册表实例化Bean
- 将Bean实例放到Spring容器中(Bean缓存池)
- 使用Bean
- 读取Bean配置信息, 生成注册表(利用反射)
- 支持的功能
- 依赖注入
- 依赖检查
- 自动装配
- 支持集合
- 指定初始化方法和销毁方法
- 支持回调方法
- BeanDefinition
- 主要用来描述Bean的定义
- 会被包装为
<String(name), BeanDefinition>的ConcurrentHashMap
- BeanDefinitionRegistry
- 提供向IOC容器注册Beandefinition对象的方法
- BeanFactroy: Spring框架最核心的接口
- 提供IOC的配置机制
- 包含Bean的各种定义, 便于实例化Bean
- 建立Bean之间的依赖关系
- Bean生命周期的控制
- BeanFactory与ApplicationContext的比较
- BeanFactory是Spring框架的基础设施, 面向Spring
- ApplicationContext面向使用Spring框架的开发者
- ApplicationContext的功能(继承多个接口)
- BeanFactory: 能够管理、装配Bean
- ResourcePatternResolver: 能够加载资源文件
- MessageSource: 能够实现国际化等功能
- ApplicationEventPublisher: 能够注册监听器, 实现监听机制
AOP
织入方式:
- 编译时织入: 需要特殊的Java编译器, 如AspectJ
- 类加载时织入: 需要特殊的Java编译器, 如AspectJ和AspectWerkz
- 运行时织入: Spring采用的方式, 通过动态代理的方式, 实现简单
- java
@Pointcut("execution(public * com.xxx.xxx.controller..*.*(..))") public void webLog(){} @Before("webLog()") public void doBefore(JoinPoint joinPoint) { ServletRequestAttributes attributes = (ServletRequestAttributes) Request HttpServletRequest request = attributes.getRequest(); } 重要名词解释
- Aspect: 通用功能的代码实现
- Target: 被织入Aspect的对象
- Join Point: 可以作为切入点的机会, 所有方法都可以作为切入点
- Pointcut: Aspect实际被应用在的Join Point, 支持正则
- Advice: 类里的方法以及这个方法如何织入到目标方法的方式
- 前置通知
- 后置通知
- 异常通知
- 最终通知
- 环绕通知
- Weaving: Aop的实现过程
AOP实现
- 由AopProxyFactory根据AdvisedSupport对象的配置来决定
- 默认策略如果目标类是接口, 则用JDKProxy来实现, 否则用后者
- JdkProxy核心: InvocationHandler接口和Proxy类
- 通过Java的内部反射机制实现
- 反射机制在生成类的过程中比较高效
- Cglib: 以继承的方式动态生成目标类的代理
- 借助ASM实现
- ASM在生成类之后的执行过程中比较高效
- Spring里的代理模式的实现
- 真实实现类的逻辑包含在了getBean方法里
- getBean方法返回的实际上是Proxy的实例
- Proxy实例是Spring采用JDK Proxy或Cglib动态生成的
Spring事务
| 事物传播策略 | 效果 |
|---|---|
| REQUIRED | 支持当前事务,如果没有事务会创建一个新的事务 |
| SUPPORTS | 支持当前事务,如果没有事务的话以非事务方式执行 |
| MANDATORY | 支持当前事务,如果没有事务抛出异常 |
| REQUIRES_NEW | 创建一个新的事务并挂起当前事务 |
| NOT_SUPPORTED | 以非事务方式执行,如果当前存在事务则将当前事务挂起 |
| NEVER | 以非事务方式进行,如果存在事务则抛出异常 |
| NESTED | 如果当前存在事务,则在嵌套事务内执行。如果当前没有事务,则进行与PROPAGATION_REQUIRED类似的操作。 |