【面经】蚂蚁金服-java-社招

今年的面经，最后一份了，请大佬们参考。

线程池 什么时候到达最大线程数 到达最大线程后继续提交的表现
用过哪些锁， synchronized ReentrantLock
可重入锁是什么，如何实现
MySQL，事务隔离级别，什么时候脏读，什么时候读已提交
业务中redis如何保证可用性
怎么实现分布式锁（redis）
设计模式的应用 装饰者模式 责任链模式
责任链模式用之前后区别/好处
责任链模式和策略模式区别
责任链模式和装饰者模式的区别

讲讲对JVM的理解，讲了GC
讲讲对设计模式的理解和运用，讲了责任链、生产者消费者
分布式事务（经常被问到）
1、两阶段提交（2PC）
第一阶段：事务协调器要求每个涉及到事务的数据库预提交(precommit)此操作，并反映是否可以提交.
第二阶段：事务协调器要求每个数据库提交数据。
优点： 尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）
缺点： 实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景，如果分布式系统跨接口调用，目前 .NET 界还没有实现方案。
2、补偿事务（TCC）
针对每个操作，都要注册一个与其对应的确认和补偿（撤销）。Try、Confirm、Cancel
优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些
缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。
3、本地消息表（异步确保）
核心思想是将分布式事务拆分成本地事务进行处理，消息生产方，需要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。然后消息会经过MQ发送到消息的消费方。如果消息发送失败，会进行重试发送。
优点： 一种非常经典的实现，避免了分布式事务，实现了最终一致性。在 .NET中 有现成的解决方案。
缺点： 消息表会耦合到业务系统中，如果没有封装好的解决方案，会有很多杂活需要处理。
4、MQ事务消息
RocketMQ支持，RabbitMQ 和 Kafka 都不支持，一次发送消息和一次确认消息，生产方需要实现一个check接口（确认消息或者回滚）
优点： 实现了最终一致性，不需要依赖本地数据库事务。
缺点： 实现难度大，主流MQ不支持，没有.NET客户端，RocketMQ事务消息部分代码也未开源。
5、Sagas事务模型
长时间运行的事务，该模型其核心思想就是拆分分布式系统中的长事务为多个短事务，或者叫多个本地事务，然后由 Sagas
工作流引擎负责协调，如果整个流程正常结束，那么就算是业务成功完成，如果在这过程中实现失败，那么Sagas工作流引擎就会以相反的顺序调用补偿操作，重新进行业务回滚。
输入一个URL按下回车发生了什么？
像DNS服务器请求解析域名对应的IP地址
建立HTTP连接，因为应用层的HTTP协议是基于网络层的TCP协议的，因此需要建立TCP连接（三次握手）
发送http请求（该请求报文作为TCP三次握手的第三个报文传送给服务器）
服务器对请求做出响应，返回HTML文本
结束tcp连接（四次挥手）
浏览器解析HTML文本并显示