java高频面试题整理

本文整理了Java面试中常见的问题,重点讨论了事务的四大特性:原子性、一致性、隔离性和持久性,详细解释了不同隔离级别的含义和应用场景。此外,还涉及了分布式事务的实现案例以及数据库优化策略,包括索引建立和查询优化。最后提到了分布式技术如分布式缓存、分布式服务和CAP理论。
摘要由CSDN通过智能技术生成

【高频常见问题】

1、事务的特性

  • 原子性:即不可分割性,事务要么全部被执行,要么就全部不被执行。
  • 一致性或可串性:事务的执行使得数据库从一种正确状态转换成另一种正确状态
  • 隔离性:在事务正确提交之前,不允许把该事务对数据的任何改变提供给任何其他事务,
  • 持久性:事务正确提交后,其结果将永久保存在数据库中,即使在事务提交后有了其他故障,事务的处理结果也会得到保存。

2、事务的隔离级别

读未提交(Read Uncommitted):可以读取未提交的记录。

如果一个事务已经开始写数据,则另外一个事务不允许同时进行写操作,但允许其他事务读此行数据,该隔离级别可以通过“排他写锁”,但是不排斥读线程实现。这样就避免了更新丢失,却可能出现脏读,也就是说事务B读取到了事务A未提交的数据。

解决了更新丢失,但还是可能会出现脏读

读已提交(Read Committed):事务中只能看到已提交的修改。

如果是一个读事务(线程),则允许其他事务读写,如果是写事务将会禁止其他事务访问该行数据,该隔离级别避免了脏读,但是可能出现不可重复读。事务A事先读取了数据,事务B紧接着更新了数据,并提交了事务,而事务A再次读取该数据时,数据已经发生了改变。

解决了更新丢失和脏读问题

可重复读(Repeatable Read):解决了不可重复读问题(MySQL 默认隔离级别)

可重复读取是指在一个事务内,多次读同一个数据,在这个事务还没结束时,其他事务不能访问该数据(包括了读写),这样就可以在同一个事务内两次读到的数据是一样的,因此称为是可重复读隔离级别,读取数据的事务将会禁止写事务(但允许读事务),写事务则禁止任何其他事务(包括了读写),这样避免了不可重复读和脏读,但是有时可能会出现幻读。(读取数据的事务)可以通过“共享读镜”和“排他写锁”实现。

解决了更新丢失、脏读、不可重复读、但是还会出现幻读

序列化(Serializable):最高隔离级别。

提供严格的事务隔离,它要求事务序列化执行,事务只能一个接着一个地执行,但不能并发执行,如果仅仅通过“行级锁”是无法实现序列化的,必须通过其他机制保证新插入的数据不会被执行查询操作的事务访问到。序列化是最高的事务隔离级别,同时代价也是最高的,性能很低,一般很少使用,在该级别下,事务顺序执行,不仅可以避免脏读、不可重复读,还避免了幻读

解决了更新丢失、脏读、不可重复读、幻读(虚读)

3、分布式事务实现

一个实际案列,电商平台分为订单中心,商品中心,提交订单时需要同时扣减库存和生成订单,

扣减库存先采用预扣库存(预占),然后生成预提交,然后扣减库存,最后订单正式提交,预订单有定时取消功能,30分钟未正式提交的订单取消,同时释放库存。

跨库2pc(准备,提交 ),跨库3pc(准备,预提交,提交),跨应用分布式事务TCC(预留,提交,撤回),RocketMQ 事务消息 本地发送一个half消息到mq-->mq返回成功-->执行本地事务-->提交事务消息给mq 结束,如果出现超时,mq会使用通知补偿方式联系生产者,会重试15次。

4、数据库优化

建索引,合适的组合索引,排序和where条件用一个索引,不要使用<>、 !=、 not null、 not in 、 null、 ‘like %%’等条件,少用子查询使用join代替,使用合适的聚合索引。

执行计划说明:

5、分布式技术

分布式分为分布式缓存(Redis)、分布式锁(Redis 或 Zookeeper)、分布式服务(Dubbo 或 SpringCloud)、分布式服务协调(zookeeper,nacos)、分布式消息队列(Kafka 、RocketMq)、分布式 Session 、分布式事务、分布式搜索(Elasticsearch)等

CAP ,分布式 CAP 理论,任何一个分布式系统都无法同时满足 Consistency(一致性)、Availability(可用性)、Partition tolerance(分区容错性) 这三个基本需求;

而 Partition tolerance(分区容错性) 是必须的,因此一般是 CP ,或者 AP。

分布式消息队列:

kafka和RocketMq区别

1)、Kafka是一个分布式、分区的、多副本的、多订阅者,基于zookeeper协调的分布式消息系统,比较常用于日志收集系统,和消息系统等,不支持事务消息;kafka对与zookeeper是强依赖的,是以zookeeper作为基础的,即使不做集群,也需要zk的支持。每个主题可以有多个区,每个区数据保证数据有序,分区之间不保证有序;而Kafka在达到几百个topic的时候吞吐量就会大幅下降,因为Kafka的topic数量不能太多,受到zookeeper协调策略和消息文件存储设计的制约;

2)、RocketMQ由NameServer注册中⼼集群、Producer⽣产者集群、Consumer消费者集群和若⼲Broker(RocketMQ进程)组成,支持事务消息;消息发送应该弱依赖注册中⼼,⽣产者在第⼀次发送消息的时候从NameServer获取到Broker地址后缓存到本地,如果NameServer整个集群不可⽤,短时间内对于⽣产者和消费者并不会产⽣太⼤影响;每个主题一个文件; rocketmq可以支持成百上千的topic;

【互联网大厂面试题合集】

1、互联网大厂java面试题-阿里

2、互联网大厂java面试题一美团

3、互联网大厂java面试题一京东

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值