java知识体系
2024-01-09 17:44:01 0 举报
AI智能生成
登录查看完整内容
0基础学java
作者其他创作
大纲/内容
原子性:同一个事务中的sql操作,要么全部成功,要么全部失败
一致性:事务将数据库从一种状态转变为下一种一致的状态
隔离性:一个事务的未提交操作对于其他事务是不可见的状态
持久性:一个事务执行完成,数据会永久保存在数据库中
事务的基本特性(acid)
脏读:一个事务读到了另一个事务未提交的数据
不可重复读:t1读到数据a,t2对数据a进行修改,t1读到的数据为t2修改后的数据
并发事务带来的问题
读未提交:一个事务读到另一个事务未提交的数据、
读已提交:一个事务读到另一个事务已经提交的数据
可重复读:一次事务开始之后,无论读取多少次,读到的数据都是相同的
可串行化:一个事务执行之后,下一个事务才能开始执行
事务的隔离级别
不同隔离级别带来的问题
Propagation.REQUIRED(default):如果当前存在事务,则加入该事务,如果当前不存在事务,则创建一个新的事务。
Propagation.SUPPORTS:如果当前存在事务,则加入该事务;如果当前不存在事务,则以非事务的方式继续运行。
Propagation.MANDATORY:如果当前存在事务,则加入该事务;如果当前不存在事务,则抛出异常。
Propagation.REQUIRES_NEW:重新创建一个新的事务,如果当前存在事务,延缓当前的事务。
Propagation.NOT_SUPPORTED:以非事务的方式运行,如果当前存在事务,暂停当前的事务。
Propagation.NEVER:以非事务的方式运行,如果当前存在事务,则抛出异常。
Propagation.NESTED:如果没有,就新建一个事务;如果有,就在当前事务中嵌套其他事务。
事务的七种传播行为(spring)
事务
主键索引结构
非主键索引结构
innodb
索引结构
myisam
1. InnoDB支持事务,MyISAM不支持,对于InnoDB每一条SQL语言都默认封装成事务,自动提交,这样会影响速度,所以最好把多条SQL语言放在begin和commit之间,组成一个事务;
2. InnoDB支持外键,而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败;
3. InnoDB是聚集索引,使用B+Tree作为索引结构,数据文件是和(主键)索引绑在一起的(表数据文件本身就是按B+Tree组织的一个索引结构),必须要有主键,通过主键索引效率很高。但是辅助索引需要两次查询,先查询到主键,然后再通过主键查询到数据。因此,主键不应该过大,因为主键太大,其他索引也都会很大。MyISAM是非聚集索引,也是使用B+Tree作为索引结构,索引和数据文件是分离的,索引保存的是数据文件的指针。主键索引和辅助索引是独立的。
4. InnoDB不保存表的具体行数,执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数,执行上述语句时只需要读出该变量即可,速度很快(注意不能加有任何WHERE条件);
5. Innodb不支持全文索引,而MyISAM支持全文索引,在涉及全文索引领域的查询效率上MyISAM速度更快高;PS:5.7以后的InnoDB支持全文索引了
6. MyISAM表格可以被压缩后进行查询操作
7. InnoDB支持表、行(默认)级锁,而MyISAM支持表级锁
8、InnoDB表必须有唯一索引(如主键)(用户没有指定的话会自己找/生产一个隐藏列Row_id来充当默认主键),而Myisam可以没有
9、Innodb存储文件有frm、ibd,而Myisam是frm、MYD、MYI Innodb:frm是表定义文件,ibd是数据文件 Myisam:frm是表定义文件,myd是数据文件,myi是索引文件
innodb 和 myisam的区别
存储引擎
概念用途:用于高效获取数据的一直方式
匹配规则:最左匹配原则
b+tree
hash
索引结构:
hash索引不支持排序,范围查询
hash索引存在hash碰撞问题
hash索引不支持联合索引最左匹配原则
hash索引等值查询效率高于btree
hash索引和btree索引的区别:
索引
表锁:粒度大,开销小
行锁:粒度小,开销大,并发高
表/行锁
悲观锁:并发低,需要锁等待
乐观锁:并发控制,一个数据多个版本(cas 版本号)
乐观/悲观锁
读锁(共享锁):阻塞写,不阻塞读
写锁(排他锁):阻塞写,阻塞读
读/写锁
要避免幻读可以用间隙锁在Session_1下面执行update account set name ='zhuge' where id > 10 and id <=20;,则其他Session没法在这个范围所包含的间隙里插入或修改任何数据
间隙锁
mvvc(多版本并发控制):维持一个数据的多个版本,使得读写操作没有冲突
锁
作用:用于复制,在主从复制中,从库利用主库上的binlog进行重播,实现主从同步;用于数据库的基于时间点的还原什么时候产生:事务提交的时候,一次性将事务中的sql语句或者是修改过后的语句按照一定的格式记录到binlog中什么时候释放:由参数expire_logs_days决定
二进制日志(binlog)
作用:当数据库对数据做修改的时候,需要把数据页从磁盘读到buffer pool中,然后在buffer pool中进行修改,那么这个时候buffer pool中的数据页就与磁盘上的数据页内容不一致,称buffer pool的数据页为dirty page 脏数据,如果这个时候发生非正常的DB服务重启,那么这些数据还没在内存,并没有同步到磁盘文件中(注意,同步到磁盘文件是个随机IO),也就是会发生数据丢失,所以在重启mysql服务的时候,可以根据redo log进行重做,从而达到事务的持久性内容:物理日志,即记录修改后的数据行什么时候产生:事务开始之后产生redo log什么时候释放:当对应事务的脏页写入到磁盘之后,redo log即可被覆盖
重做日志(redo log)
作用:保存了事务发生之前的数据的一个版本,可以用于回滚,同时可以提供多版本并发控制下的读(MVCC)内容:物理日志,修改前的数据行什么时候产生:事务开始之前,将当前版本生成undo log,undo也会产生redo来保证undo log的可靠性什么时候释放:当事务提交之后,undo log并不能立马被删除,而是放入待清理的链表,由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息,决定是否可以清理undo log的日志空间
回滚日志(undo log)
log
分表
binlog线程:负责将主服务器上的数据写入二进制日志中
i/o线程:复制从主服务器上读取二进制日志,并写入从服务器的中继日志(replay log)
sql线程:夫妇在读取中继日志,解析出主服务器已经执行的数据更改并在从服务器中重放(replay)
主从复制
sem-sync:半同步
并行复制
实时性要求高的强制走主库
写完加缓存
延时怎么办
读写分离
主从
高可用
mysql
为什么要用:基于内存,高性能,高并发
基于内存操作
非阻塞io多路复用
单线程,避免多线程频繁上下文切换
为什么这么快
redis数据类型更多
redis官方支持集群
redis单线程
redis和memcached的区别
线程模型
字符串
list
set
zset有序集合
计算用户登录次数
bitmap(位图)
数据类型
scan:遍历key,不会阻塞线程
基础
开启rdb:save 60 1000
save 60 1000 60s操作1000次自动保存
save同步
bgsave异步
rdb(二进制)
什么是aof:AOF 持久化,将修改的每一条指令记录进文件appendonly.aof中
开启aof:# appendonly yes
appendfsync always:每次有新命令追加到 AOF 文件时就执行一次 fsync ,非常慢,也非常安全
appendfsync everysec:每秒 fsync 一次,足够快(和使用 RDB 持久化差不多),并且在故障时只会丢失 1 秒钟的数据。
appendfsync no:从不 fsync ,将数据交给操作系统来处理。更快,也更不安全的选择。推荐(并且也是默认)的措施为每秒 fsync 一次, 这种 fsync 策略可以兼顾速度和安全性。
aof三种模式
什么事aof重写:AOF文件里可能有太多没用指令,所以AOF会定期根据内存的最新数据生成aof文件
# auto-aof-rewrite-min-size 64mb //aof文件至少要达到64M才会自动重写,文件太小恢复速度本来就很快,重写的意义不大
# auto-aof-rewrite-percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写
入redis客户端执行命令bgrewriteaof重写AOF
aof重写的三种方式
AOF重写redis会fork出一个子进程去做,不会对redis正常命令处理有太多影响
aof重写
aof
开启混合持久化:aof-use-rdb-preamble yes
AOF在重写时,不再是单纯将内存数据转换为RESP命令写入AOF文件,而是将重写这一刻之前的内存做RDB快照处理,并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起,都写入新的AOF文件,新的文件一开始不叫appendonly.aof,等到重写完新的AOF文件才会进行改名,原子的覆盖原有的AOF文件,完成新旧两个AOF文件的替换。于是在 Redis 重启的时候,可以先加载 RDB 的内容,然后再重放增量 AOF 日志就可以完全替代之前的AOF 全量文件重放,因此重启效率大幅得到提升。
混合持久化AOF文件结构
rdb/aof混合
持久化
结构
主从复制(全量复制)
主从复制(部分复制)
选举机制:
缺点:master主节点挂了,哨兵会选举主节点(选举期间,redis会停止对外的服务)
哨兵
数据分配原理:Redis Cluster 将所有数据划分为 16384 个 slots(槽位),每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。槽位定位算法 :Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值,然后用这个整数值对 16384 进行取模来得到具体槽位。HASH_SLOT = CRC16(key) mod 16384
群是否完整才能对外提供服务:当redis.conf的配置cluster-require-full-coverage为no时,表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时,集群仍然可用,如果为yes则集群不可用。
Redis集群为什么至少需要三个master节点,并且推荐节点数为奇数?
集群
什么是缓存击穿?缓存击穿是指缓存中没有但数据库中有的数据(一般是缓存时间到期),这时由于并发用户特别多,同时读缓存没读到数据,又同时去数据库去取数据,引起数据库压力瞬间增大,造成过大压力
解决方案:设置热点数据永远不过期。加互斥锁,互斥锁参考代码如下:
缓存击穿
什么是缓存失效?由于大批量缓存在同一时间失效可能导致大量请求同时穿透缓存直达数据库,可能会造成数据库瞬间压力过大甚至挂掉
解决方案:对于这种情况我们在批量增加缓存时最好将这一批数据的缓存过期时间设置为一个时间段内的不同时间。
缓存失效
解决方案:1.接口层增加校验,如用户鉴权校验,id做基础校验,id<=0的直接拦截;2.从缓存取不到的数据,在数据库中也没有取到,这时也可以将key-value对写为key-null,缓存有效时间可以设置短点,如30秒(设置太长会导致正常情况也没法使用)。这样可以防止攻击用户反复用同一个id暴力攻击3.使用布隆过滤器
什么是缓存穿透?缓存穿透是指缓存和数据库中都没有的数据,而用户不断发起请求,如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者,攻击会导致数据库压力过大。
缓存穿透
什么是缓存雪崩?缓存雪崩指的是缓存层支撑不住或宕掉后, 流量会像奔逃的野牛一样, 打向后端存储层。由于缓存层承载着大量请求, 有效地保护了存储层, 但是如果缓存层由于某些原因不能提供服务(比如超大并发过来,缓存层支撑不住,或者由于缓存设计不好,类似大量请求访问bigkey,导致缓存能支撑的并发急剧下降), 于是大量请求都会达到存储层, 存储层的调用量会暴增, 造成存储层也会级联宕机的情况。
解决方案:1) 保证缓存层服务高可用性,比如使用Redis Sentinel或Redis Cluster。2) 依赖隔离组件为后端限流并降级。比如使用Hystrix限流降级组件。3) 提前演练。 在项目上线前, 演练缓存层宕掉后, 应用以及后端的负载情况以及可能出现的问题, 在此基础上做一些预案设定。
缓存雪崩
缓存设计
服务直接被kill 或者服务器宕机锁永远释放不了
锁释放放在finally中
加定时key失效时间
redisson实现
阿里分析
分布式锁setnx
分布式
高级
Redis
加载
验证
准备
解析
初始化
使用
退出
类加载过程
引导类加载器:负责加载支撑JVM运行的位于JRE的lib目录下的核心类库,比如rt.jar、charsets.jar等
扩展类加载器:负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR类包
应用程序类加载器:负责加载ClassPath路径下的类包,主要就是加载你自己写的那些类
自定义加载器:负责加载用户自定义路径下的类包
类加载器
什么是双亲委派:双亲委派机制说简单点就是,先找父亲加载,不行再由儿子自己加载
为什么要设计双亲委派机制?沙箱安全机制:自己写的java.lang.String.class类不会被加载,这样便可以防止核心API库被随意篡改避免类的重复加载:当父亲已经加载了该类时,就没有必要子ClassLoader再加载一次,保证被加载类的唯一性
双亲委派机制
jvm类加载机制
JVM整体结构及内存模型
什么是逃逸分析?
基于逃逸分析的优化(不逃逸的好处)
逃逸分析
1.1 对象优先在Eden区分配
1.2 大对象直接进入老年代
1.3 长期存活的对象将进入老年代
1.4 对象动态年龄判断
1.5 Minor gc后存活的对象Survivor区放不下
1.6 老年代空间分配担保机制
1.7 Eden与Survivor区默认8:1:1
分配
1 引用计数法
2 可达性分析算法
回收
强引用
软引用
弱引用
虚引用
常见引用类型
如何判断一个类是无用的类?
JVM内存分配与回收
标记-清除算法
复制算法
标记整理算法
分代收集算法
垃圾收集算法
Serial收集器(-XX:+UseSerialGC -XX:+UseSerialOldGC)
ParNew收集器(-XX:+UseParNewGC)
初始标记: 暂停所有的其他线程,并记录下gc roots直接能引用的对象,速度很快 ;
并发标记: 同时开启GC和用户线程,用一个闭包结构去记录可达对象。但在这个阶段结束,这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域,所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
重新标记: 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间一般会比初始标记阶段的时间稍长,远远比并发标记阶段时间短
并发清理: 开启用户线程,同时GC线程开始对未标记的区域做清扫
收集过程
并发收集、低停顿。
优点
对CPU资源敏感(会和服务抢资源);无法处理浮动垃圾(在并发清理阶段又产生垃圾,这种浮动垃圾只能等到下一次gc再清理了);它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生,当然通过参数-XX:+UseCMSCompactAtFullCollection 可以让jvm在执行完标记清除后再做整理执行过程中的不确定性,会存在上一次垃圾回收还没执行完,然后垃圾回收又被触发的情况,特别是在并发标记和并发清理阶段会出现,一边回收,系统一边运行,也许没回收完就再次触发full gc,也就是\"concurrent mode failure\",此时会进入stop theworld,用serial old垃圾收集器来回收
缺点
三色标记算法
CMS收集器(-XX:+UseConcMarkSweepGC(old))
G1垃圾收集器jvm堆内存结构
G1内存划分
初始标记(initial mark,STW):暂停所有的其他线程,并记录下gc roots直接能引用的对象,速度很快 ;
并发标记(Concurrent Marking):同CMS的并发标记
最终标记(Remark,STW):同CMS的重新标记
筛选回收(Cleanup,STW)
G1收集器一次GC的过程
并行与并发
分代收集
空间整合
可预测的停顿
G1被视为JDK1.7以上版本Java虚拟机的一个重要进化特征。它具备以下特点:
YoungGC
MixedGC
Full GC
G1垃圾收集分类
G1垃圾收集器优化建议
G1收集器(-XX:+UseG1GC)
垃圾收集器
jvm调优
jvm
销售部门应该直接从仓库拿货,减少生成生产部门的压力,提供效率
生活例子
缺点:以运算器为中心(输入/输出设备与存储器直接的数据传输通过运算器完成【效率降低】)
早期冯诺依曼计算机
简化结构
现代计算机
结构图
m修改
e 独享,互斥
s 共享
i 失效
缓存一致性协议失效:1.如果缓存长度大于一个缓存行,加总线锁2.cpu并不支持缓存一致性mesi协议
缓存一致性协议
多核cpu缓存架构
计算机组成原理
什么是JMM?
为什么有jmm模型?
如何理解JMM模型
Java内存模型与硬件内存架构的关系
JVM和JMM
JMM模型
会触发总线嗅探机制(更新把主内存的变量最新值更新工作内存)
什么是volatile?
作用
volatile缓存可见性实现原理
1.lock(锁定)
2.read(读取)
3.load(载入)
4.use(使用)
5.assign(赋值)
6.store(存储)
7.write(写入)
8.unlock(解锁)
Java内存模型内存交互操作
volatile会在底层添加内存屏障来禁止指令重排
内存屏障
volatile多并发高可能产生总线风暴
加了volatile 才会触发mesi协议
volatile
被Synchronized包裹的代码 依然会发生指令重排
可重入锁,非公平锁
什么是Synchronized
原理
加锁方式
每个对象都有一个自己的Monitor(监视器锁)
JVM加锁过程
对象一定存在堆区吗?
对象的内存结构
锁的粗化
锁的消除
无锁
偏向锁
轻量级锁
重量级锁
JVM内置锁优化升级过程
Synchronized
隐示锁
可重入锁
非公平锁
公平锁
同步队列
条件队列
ReentantLok
显示锁
显示/隐示 锁
会带来ABA问题,加版本号解决
CAS
AQS
乐观锁/悲观锁
什么时候使用线程池?
为什么用线程池?
线程池优势
原理图
execute(Runnable command)
submit(task)
shutdown()
shutdownNow()
isTerminated()
isShutdown()
行为
RUNNING
SHUTDOWN
STOP
TIDYING
TERMINATED
五种状态
线程池
并发
应用解耦
异步提速
削峰填谷
优势
系统可用性降低
系统复杂度提高
劣势
简单模式 HelloWorld
工作队列模式 Work Queue
发布订阅模式 Publish/subscribe
路由模式 Routing
通配符模式 Topic
五种工作模式
确认模式
退回模式
消息的可靠性投递
自动确认:acknowledge=\"none\"
手动确认:acknowledge=\"manual\"
服务端确认方式
消费端限流
TTL
消息成为死信的三种情况
死信队列
延迟队列
高级特性
RabbitMq
生产者发送消息步骤
消息消费者的固定步骤
使用方式
1、同步发送消息的样例见:org.apache.rocketmq.example.simple.Producer
2、异步发送消息的样例见:org.apache.rocketmq.example.simple.AsyncProducer
3、单向发送消息的样例:producer.sendOneWay
一种是消费者主动去Broker上拉取消息的拉模式
另一种是消费者等待Broker把消息推送过来的推模式。
4、使用消费者消费消息。
3.1 基本样例
顺序消息生产者样例见:org.apache.rocketmq.example.order.Produce
顺序消息消费者样例见:org.apache.rocketmq.example.order.Consumer
3.2 顺序消息
广播消息的消息生产者样例见:org.apache.rocketmq.example.broadcast.PushConsumer
3.3 广播消息
3.4 延迟消息
批量消息是指将多条消息合并成一个批量消息,一次发送出去。这样的好处是可以减少网络IO,提升吞吐量
相信大家在官网以及测试代码中都看到了关键的注释:如果批量消息大于1MB就不要用一个批次发送,而要拆分成多个批次消息发送。也就是说,一个批次消息的大小不要超过1MB实际使用时,这个1MB的限制可以稍微扩大点,实际最大的限制是4194304字节,大概4MB。但是使用批量消息时,这个消息长度确实是必须考虑的一个问题。而且批量消息的使用是有一定限制的,这些消息应该有相同的Topic,相同的waitStoreMsgOK。而且不能是延迟消息、事务消息等。
批量消息的消息生产者样例见:org.apache.rocketmq.example.batch.SimpleBatchProducer和org.apache.rocketmq.example.batch.SplitBatchProducer
3.5 批量消息
在大多数情况下,可以使用Message的Tag属性来简单快速的过滤信息。
SQL过滤的消息生产者案例见:org.apache.rocketmq.example.filter.SqlFilterProducer
SQL过滤的消息消费者案例见:org.apache.rocketmq.example.filter.SqlFilterConsumer
一些比较复杂的场景就有点不足了。 这时候,可以使用SQL表达式来对消息进行过滤
3.6 过滤消息
什么是事务消息?
3.7 事务消息
RocketMQ的消息样例
1 消息模型(Message Model)
2 消息生产者(Producer)
3 消息消费者(Consumer)
4 主题(Topic)
5 代理服务器(Broker Server)
6 名字服务(Name Server)
7 消息(Message)
一、基础概念:
推其实就是拉,推的话 mq需要知道消费者的状态。拉的话 不需要知道消费者状态,
1、何时存储消息
2.1磁盘保存文件慢吗?
2.2零拷贝技术加速文件读写
2、消息存储介质
3 消息存储结构
同步刷盘
异步刷盘
配置方式
4 刷盘机制
5 消息主从复制
6.1Producer负载均衡
默认:平均分配
1、集群模式
2、广播模式
6.2 Consumer负载均衡
6 负载均衡
1、如何让消息进行重试
2、重试消息如何处理
7、消息重试
8、死信队列
1、幂等的概念
9、消息幂等
二、消息存储
NameServer的核心作用
源码重点
二、NameServer启动
1、功能回顾
2、源码重点
三、Broker启动
四、Broker注册
路由管理流程
负载均衡
五、Producer
5文件存储部分的总结:
2、源码重点:
六、消息存储
三、源码解读
RocketMq
日志收集
消息系统
用户活动跟踪
运营指标
Kafka的使用场景
Broker
Topic
Producer
消费模式
消费顺序
Consumer
ConsumerGroup
Partition
为什么要对Topic下数据进行分区存储?
Kafka基本概念
Controller选举机制
Kafka核心总控制器Controller
Partition副本选举Leader机制
消费者消费消息的offset记录机制
消费者Rebalance机制
producer发布消息机制剖析
HW与LEO详解
深入理解kafa
消息发送端:
消息消费端:
1、消息丢失情况:
2、消息重复消费
3、消息乱序
4、消息积压
5、延时队列
6、消息回溯
7、分区数越多吞吐量越高吗
8、消息传递保障
9、kafka的事务
10、kafka高性能的原因
线上问题及优化
kafka
四大MQ
mq
进程内调度
调度模型
分片
资源最大限度利用
弹性调度
需要手动开启,但是耗性能
失效转移
错过任务重执行
概念 & 功能
简单作业
数据流作业
脚本作业
HTTP作业(3.0.0-beta 提供)
作业开发
记录日志策略
抛出异常策略
忽略异常策略
邮件通知策略
企业微信通知策略
钉钉通知策略
配置错误处理策略
使用手册
job命名空间-对应zk的一个目录
jobName
分片总数
shardingTotalCount
cron
timeZone
当前机器分片参数
shardingItemParameters
jobParameter
是否开启zk监控
monitorExecution
* 只有对monitorExecution的情况下才可以开启失效转移.
是否开启失败转移
failover
任务错过重执行机制
misfire
maxTimeDiffSeconds
reconcileIntervalMinutes
默认
平均分片策略
奇偶分片策略
轮询分片策略
分片策略
jobShardingStrategyType
jobExecutorServiceHandlerType
jobErrorHandlerType
jobListenerTypes
description
props
子主题
设置作业是否启动时禁止.
disabled
设置本地配置是否可覆盖注册中心配置.
overwrite
作业配置
参数说明
elastic-job-lite
什么是http?http是 超文本 传输 协议
client:\"我要开始了\"server:\"好的\"client:\"那我真的开始了\"
定义
为什么要三次握手
三次握手
client:\"我要结束啦\"server:\
为什么要四次挥手
四次挥手
tcp/ip
http
HTTPS (全称:Hyper Text Transfer Protocol over SecureSocket Layer),是以安全为目标的 HTTP 通道,在HTTP的基础上通过传输加密和身份认证保证了传输过程的安全性
TLS/SSL是一种加密通道的规范
https
可重入锁指的是在一个线程中可以多次获取同一把锁,比如:一个线程在执行一个带锁的方法,该方法中又调用了另一个需要相同锁的方法,则该线程可以直接执行调用的方法,而无需重新获得锁;
题主想问的其实是可重入锁的必要性,如果不用重入会导致什么问题。关于别的回答里面说的递归调用,跟重不重入其实关系不大,正常人不会递归调用加锁的方法,跟在外面加一把锁里面再去递归调用的意义没什么区别,所以说服性不强。
public class LockTest { static ReentrantLock lock = new ReentrantLock(); public void m1(){ lock.lock(); try { m2(); }finally { lock.unlock(); } } private void m2() { //既然m1已经加锁了,为什么m2还需要加锁?不加锁一样能够保证m1调用m2的安全性 lock.lock(); try { System.out.println(\"同步代码块\"); }finally { lock.unlock(); } }}
在这段代码中,m1调用了m2,既然m1已经加锁了,为什么还要给m2加锁?原因是 既然m2独立出来成了一个方法,你就没法保证你在调用m1的方法的同时,别的人不通过m1调用m2,而是直接调用m2。如果m2不加锁,这里就必然会出现线程安全问题。
Ribbon本地负载均衡和Nginx服务器端负载均衡的区别
ioc
spring
自动装配原理
spring boot
warm up
排队等待
流控规则
RT
异常比例
异常数
降级规则
@SentinelResource(\"\")
热点规则
sentinel
feignClient 可以使用相同的 name属性
整合feign
spring cloud
分布式事务
谈谈中间件开发
搭建日志处理系统的需求原因
收集-能够采集多种来源的日志数据 ---logstash、fluent bit
传输-能够稳定的把日志数据传输到中央系统 ----MQ(rabbitmq/kafka)
存储-如何存储日志数据 --ElasticSearch/Redis/Kafka等
分析-可以支持 UI 分析 -- grafana/kibana 等
警告-能够提供错误报告,监控机制 -- Prometheus的监视系统 - 简书
集中式日志系统,包含几个主要特点
日志采集的可行性方案
系统架构图示例
elk+fileBeat
java体系
0 条评论
回复 删除
下一页