Java扫盲
2025-12-14 23:11:49 0 举报
AI智能生成
面试知识点归纳
作者其他创作
大纲/内容
SQL
sql优化
索引优化
性能调优
分库分表
数据灾备
数据迁移
mysql MVCC
事务4个特性
MYSQL锁
行锁,表锁,乐观锁,悲观锁,排他锁,共享锁
行锁
分为共享锁和排他锁
基于索引,不走索引不会使用行锁,会使用表锁
表锁
有索引的情况下是行锁,没有索引的表是锁定全表的
排他锁
写锁
对某一行加排他锁之后,只能这个事务进行读写,在结束之前,其他事务不能对其进行加任何锁。其他进程可以读不能写。
共享锁
读锁
所有事务只能对其进行读不能写,事务结束之前,其他事务只能对其加共享锁,除此之外其他任何锁都不能加。
悲观锁
共享锁和排他锁是悲观锁的不同实现
乐观锁
用版本号 Version 机制实现,最常见的一种实现方式
MySQL死锁排查
MySQL优化
事务隔离级别
MySQL默认可重复读,Orcale默认读已提交
未提交读 RN
子主题
已提交读 RC
可重复读 RR
串行化的 Serializable
事务的传播行为
7中传播行为
保证同一个事务中
如果不存在,就新建一个(默认)
如果不存在,就不使用事务
如果不存在,抛出异常
保证没有在同一个事务中
如果有事务存在,挂起当前事务,创建一个新的事务
已非事务方式允许,如果有事务存在,挂起当前事务
已非事务方式允许,如果有事务存在,抛出异常
如果当前事务存在,则嵌套事务执行
JVM
调优案例
MQ
RocketMQ
kafka
Redis
集群搭建
冷热备份
性能调优
数据迁移
用Redis做过什么?
Redis是如何持久化的?rdb和aof
Redis数据类型
五种数据类型介绍
String,List,Hash,Set ,ZSet
Redis集群如何同步
Redis的数据添加过程是怎样的:哈希槽
Redis的淘汰策略有哪些
内存淘汰机制
volatile-lru
allkeys-lru
volatile-random
allkeys -> random
volatile-ttl
noeviction
Redis的单线程模型
Redis集群基础
redis Cluster 主从模式
如何使用Redis实现分布式锁
自动化部署
git
Jenkins
网络通信
浏览器访问www.baidu.com经历了什么
其他
假如你的项目出现了性能瓶颈了,你觉得可能会是哪些方面,怎么解决问题?
如何查找造成性能瓶颈出现的位置,是哪个位置造成的性能瓶颈
并发编程
synchronized
双重检查锁
锁升级过程
Java语言关键字,内置特性
CAS底层实现原理
优点
缺点
ABA问题
Lock
是一个接口java.util.concurrent.locks包中,Lock是一个接口
Lock,必须主动去释放锁,使用Lock必须在try{}catch{}块中进行,释放锁在finally块,防止死锁的发生
ReentrantLock是唯一实现了Lock接口的类
ReadWriteLock
ReentrantReadWriteLock
ConcurrentHashMap
JDK 1.7 版本,它的实现方式是分段加锁,将HashMap在底层的数组分段成几个小数组,然后给每个数组分别加锁,
所以JDK1.7的底层是:segments+HashEntry数组
所以JDK1.7的底层是:segments+HashEntry数组
JDK1.8以及之后,锁粒度的细化,底层是散列表+红黑树和HashMap是一样的
数组中每个元素进行put都是有一个不同的锁,如果两个线程都是在数组[5]这个位置进行put,这个时候,对数组[5]这个位置进行put的时候,采取的是CAS策略
如果很多个线程对数组中不同位置的元素进行操作,大家是互相不会影响的
如果多个线程对同一个位置进行操作,产生冲突,CAS失败的线程,就会在这个位置基于链表+红黑树来进行处理,synchronized([5]),进行加锁。
ConcurrentHashMap的key和Value都不能为nul
hashmap的key和Value都可以为null
AQS
AQS的全称是AbstractQueuedSynchronizer,抽象队列同步器
ReentrantLock和AQS之间的关系:说白了,ReentrantLock内部包含了一个AQS对象,也就是AbstractQueuedSynchronizer类型的对象。这个AQS对象就是ReentrantLock可以实现加锁和释放锁的关键性的核心组件
实现原理
1,AQS对象内部有一个核心的变量叫做state,是int类型的,代表了加锁的状态。初始状态下,这个state的值是0
2,AQS内部还有一个关键变量,用来记录当前加锁的是哪个线程,初始化状态下,这个变量是null
线程1跑过来调用ReentrantLock的lock()方法尝试进行加锁,这个加锁的过程,直接就是用CAS操作将state值从0变为1。设置当前加锁线程是线程1
线程2跑过来一看,state的值不是0啊?所以CAS操作将state从0变为1的过程会失败,因为state的值当前为1,说明已经有人加锁了!
- 线程2会看一下,是不是自己之前加的锁啊?如果不是,此时就是加锁失败。
- 线程2会将自己放入AQS中的一个等待队列
- 如果是自己之前加的锁,将aqs里面的state加1。
线程1在执行完自己的业务逻辑代码之后,就会释放锁
- 将AQS内的state变量的值递减1,如果state值为0,则彻底释放锁
- 将“加锁线程”变量也设置为null
- 从等待队列的队头唤醒线程2重新尝试加锁
ReentrantLock这种东西只是一个外层的API,内核中的锁机制实现都是依赖AQS组件的
线程池
系统是不可能频繁的创建线程有销毁线程的,这样会非常影响性能,所以我们需要线程池。
池化技术
关键参数
拒绝策略
- 默认:AbortPolicy:丢弃任务并抛出RejectedExecutionException异常,比较关键的业务,推荐使用此拒绝策略
- DiscardPolicy:丢弃任务,但是不抛出异常。如果线程队列已满,则后续提交的任务都会被丢弃,无关紧要的业务采用此策略。例如,博客网站统计阅读量就是采用的这种拒绝策略
- DiscardOldestPolicy:丢弃队列最前面的任务,然后重新提交被拒绝的任务,根据实际业务是否允许丢弃老任务来认真衡量。
- CallerRunsPolicy:由调用主线程处理该任务
Java提供的四种线程池实现
Java内存模型
volatile
变量可见性,其一是保证该变量对所有线程可见,这里的可见性指的是当一个线程修改了变量的值,那么新的
值对于其他线程是可以立即获取的
值对于其他线程是可以立即获取的
volatile 禁止了指令重排
volatile最关键的几个作用
基于内存屏障保证可见性和有序性
lock指令:volatile保证可见性
内存屏障:volatile禁止指令重排序
使用场景
如果仅仅只是有一些线程会来写一个变量,标志位,另外一个线程是来读取这个标志位的值,那么此时优先使用volatile
ThreadLocal
ThreadLocal是通过每个线程单独一份存储空间,牺牲空间来解决冲突,并且相比于Synchronized,ThreadLocal具有线程隔离的效果,只有在线程内才能获取到对应的值,线程外则不能访问到想要的值
数据结构
ThreadLocal的静态内部类ThreadLocalMap为每个Thread都维护了一个数组table(table里面存的就是ThreadLocal变量),
源码中:private Entry[] table;
也就是说一个线程中可以定义多个ThreadLocal变量
源码中:private Entry[] table;
也就是说一个线程中可以定义多个ThreadLocal变量
应用场景
如果你不需要多个线程共享读写一个数据的话,可以让每个线程保持一个本地变量的副本的话,那么你其实可以搞一个ThreadLocal,让每个线程都维护一个变量的副本,每个线程就操作自己本地的副本就可以了
CountDownLatch、CyclicBarrier、Semaphore
CountDownLatch(线程计数器)
Semaphore
信号量-控制同时访问的线程个数,通过acquire() 获取一个许可,如果没有就等待,而 release() 释放一个许可
jdk并发包
微服务
Dubbo
默认使用什么通信框架,还有别的选择吗
默认也推荐使用netty框架,还有mina
服务调用是阻塞的吗
默认是阻塞
可以异步调用,没有返回值可以这么做
一般使用什么注册中心?还有别的选择吗
推荐使用zookeeper注册中心,还有Redis等不推荐
默认使用什么序列化框架,你知道的还有哪些
默认使用Hessian,还有Dubbo,FastJson ,Java自带序列化
服务上线怎么不影响旧版本?
采用多版本开发
如何解决服务调用链过长的问题?
可以结合Zipkin实现分布式服务追踪
说说核心的配置有哪些
dubbo:service/ dubbo:reference/ ...
同一个服务多个注册的情况下可以直连某一个服务吗
可以直连,修改配置即可,也可以通过telnet直连某个服务
画一画服务注册与发现的流程图
集群容错怎么做
支持几种负载均衡策略
推荐使用什么协议
使用过程中有遇到过什么问题
还了解别的分布式框架吗
Dubbo定位是一款RPC框架,而SpringCloud 的目的是微服务架构下的一站式解决方案
SpringCloud
Eureka
Ribbon
Feign
Hystrix
Zuul
微服务架构下的一站式解决方案
Gateway
Nacos
Sentinel
Seata
Appollo配合中心
Zooleeper
Zooleeper是什么
Zooleeper哪里用到
Zooleeper选主过程
Zooleeper集群之间如何通信
分布式锁的实现过程
建模工具
PowerDesign
Visio
设计模式
单例模式:饱汉,饿汉,以及饿汉中的懒加载,双重检查
工厂模式,装饰者模式,观察者模式,策略模式
工厂方法有点
低耦合,高内聚,开放封闭原则
测试
功能测试
单元测试
冒烟测试
集成测试
QA测试
性能测试
Jmeter
LoadRunner
自动化测试
selenium
QTP
锁
产生死锁的必要条件
产生,条件,解锁
分布式架构
分布式session
分布式锁
Rpc调用
接口幂等性
子主题
分库分表
分布式事务
2PC
基于XA协议的两阶段提交
XA规范主要定义了事务管理器和资源管理器之间的接口
两阶段提交
事务的提交分为两个阶段
预提交阶段
决策后阶段
TCC
补偿事务
针对每个操作,都需要注册一个与其对应的确认和补偿(撤销)操作,分为3个阶段
try:对业务系统做检查及资源预留
confirm:对业务系统做确认提交,try阶段执行成功并执行confirm时,默认confirm阶段是不会出错的;即只要try成功confirm一定成功
cancel:业务执行错误,需要回滚的状态下执行的业务取消,预留资源释放
可靠性消息最终一致性方案
最大努力通知方案
saga
核心思想是将分布式系统中的一个长事务拆分为多个短事务,或者叫多个本地事务,然后由sagas工作流引擎负责协调,如果整个工作流正常结束,那么就算是业务成功;如果在这个过程中失败了,那么工作流引擎就会以相反的顺序调用补偿操作,重新进行业务回滚。
分布式id生成算法
0 条评论
下一页