写在前面：

最终拿到了虾皮和阿里offer，进了阿里

对了，有需要的可能找我内推，我们是阿里国际化中台事业部，新零售行业的跨境电商平台。新业务，新起点，有兴趣私我或者留言

快手：

1.http四次挥手--报文传递参数是什么

2.进程间的通行方式

• 管道 -- 无名管道（具有亲缘关系的进程使用）和有名管道（允许无亲缘关系进程通信）
• 信号
• 信号量（计数器--锁）
• 消息队列（可以传输大量数据）
• 共享内存
• 套接字（不同机器之间的通信）socket

3.mysql加锁问题

乐观锁

update table set x = 1, version = #{version} where id = #{id} and version = #{version}

悲观锁

select * from table for update(写锁，排他锁) 必须要在事务中才可以起作用

4.java自带的线程

• 继承Thread
• 实现Runable接口（创建了一个线程对象，需要重新new一个线程来启动）
• 实现Callable接口（有返回值）

5.redis的string的底层实现

6.分布式事务

6.mysql的索引，innodb的行锁的理解

算法：两个排序数组中找第k大的数 （面试官强烈要求你用二分法，难度hard）

两个排序数组中找第k大的数_qiki_糖没味儿的程序媛小屋-CSDN博客

吐槽吐槽：快手和抖音的特点都是对网络传输有很高的要求，因此在面试中除了一些基础的题目以外，更多的是网络传输的相关知识点考察。对了，当面写算法也是必不可少的。

虾皮：

1.syn关键字底层实现

就是内存屏障命令啦！主要是通过moniter指令来进行的。简单来说，每个synchronized的前后都有一个monitor与之关联，每当一个moniter被持有后，就处于锁定状态。分别有monitorenter和monitorexit

2.双亲委派机制

3.mysql索引==== B+ 日志问题（3个）

4.限流算法------令牌桶和漏抖算法

5.redis分布式锁的底层lua setnx

6.消息队列---推拉模式--- mq丢失情况探究

7.乐观锁--悲观锁

1.乐观锁

对一切都保持乐观态度，认为在数据同步过程中不会其他线程修改数据，所以不会加锁

实现方式

1.版本控制
update table set x = 1, version = #{version} where id = #{id} and version = #{version}
2.CAS算法
boolean CAS(v, A, B);
//V-内存地址 A-预期值 B-新值
//当V等于A的情况下，才会把A的值更新为B
CAS的缺点：

2.1.ABA问题
初次读取值A，然后他的值变为B，然后在改回A，那么CAS认为没有改变过
解决办法：
AtomicStampedReference类：检查值符合预期的同时，也要检查引用（版本号）是否符合预期
2.2 自旋时间长，开销大
多个请求并发的情况下，每个请求都会自旋（不成功就会一直循环到成功），如果长时间不成功，那么就会给CPU带来很大的开销
解决办法：增加自旋次数判断
2.3 单个变量原子性，多个变量无解
比如查询表1，然后更新表2的情况
使用场景：

3.1 功能限制

乐观锁使用场景受限，只能保证单个变量的原子性，涉及多个变量，就无解
悲观锁的synchronized关键字，可以对整个代码块加锁
版本号控制情况，查询表1，然后更新表2的数据，就很难依靠版本号实现
3.2 竞争激烈程度

当竞争不激烈情况下（并发冲突比较小），乐观锁更有优势，因为悲观锁会锁住整个代码块或者数据，其他线程无法同时访问，印象并发。而且加锁和释放锁都需要额外的资源。
当竞争激烈的情况下（并发冲突比较大），悲观锁更有效率，因为乐观锁在执行更新时，频繁的自旋，需要不断的重试，浪费CPU资源
对数据更新频繁的场合，悲观锁效率更高
对于数据跟新不频繁的场合，乐观锁效率更高
2.悲观锁

对一切保持悲观态度，认为数据同步过程一定会有其他线程来修改数据，因此在获取数据过程前要做加锁操作。

2.1 悲观锁的实现方式

java里的synchronized
比如行锁，表锁等
select * from table for update(写锁，排他锁) 必须要在事务中才可以起作用
2.2 悲观锁的缺点

1.多线程竞争情况，加锁和释放锁对上下文切换和调度，都会引起性能问题。
2.一个线程持有锁会导致其他所有线程挂起
3.一个优先级高的线程会等待一个优先级低的线程释放锁，导致优先级倒置

8.JVM的底层结构---GC算法---可达性分析

10.线程池队列有哪几种？

1.先判断核心线程池数，核心数不够在判断最大线程池数。再不够判断等待队列数，再不够直接丢弃。（参数keepAliveTime:线程最大空闲时间，超过就回收线程）
2.线程池队列：(有界队列)ArrayBlockingQueue,
(无界队列)LinkedBlockingQeque,
(优先级队列)PriorityBlockingQueue，
(无存储队列)SynchronousQueue，有空闲队列就执行

吐槽吐槽：虾皮本身面试很速度的，而且面试场景都是比较常规的，问题基本集中在mysql，redis和项目上。题目也是比较简单的啦！

阿里：

1.并发大的情况下，核心线程池该如何设置参数？大流量进来会不会堵塞整个流程（通过扩容服务器的方式?）

这里解释一个核心线程池里最大线程池的参数，找了好久才找到的，你要看你的项目是IO密集型还是CPU密集型，因为IO密集型的话，需要进行IO操作，在操作的时间，是不消耗CPU的，所以一般这种情况，你的cpu数的倍数即可，如果是cpu密集型，那么最大线程数只能设置为cpu数+1，这样留一个空出来，用来做切换。

2.锁的问题

这里总结一下，乐观锁，悲观锁，AQS以及volatile，还有synchronized

3.幂等问题？--项目中的幂等问题--本地消息表（空间换时间的概念）

幂等问题本身就是一个常规化的问题，在一般情况下，都是需要通过各种手段去处理，比如增加冗余字段，比如增加校验逻辑，或者增加补偿逻辑等。这里的核心点就是，需要花费更多的时间和空间去对幂等进行校验，那么亮点应该是如何平衡时间和空间的消耗。

4.出了一个题。

---春晚红包提现流程-----如果保证高并发可用？

数据落库 --> 专门增加一层服务用来分发请求 ----> 后面服务进行排队处理。 最终增加第三方表来做幂等（1分库分表不容易扫表，数据分散，2该表比较容易聚合，3放在其他服务上，保证可用性）

这个就是大并发下的最终一致性问题了，就是保证每个人都能正常提现，且能够正常到账。当时的提出了这样一个思路，核心点利用MQ进行串行化处理，然后让每一步的数据都可追溯，最终发钱的时候，做最终校验。

5.***服务器实例

大促来了，你需要提前考虑好，你的服务器资源是否能够承载自己的业务曲线。这个有点运维的感觉，事实上还是比较容易的，通过cpu数和内存数以及未来的QPS去做一个比例，最终结果就是你需要的结果啦！

6.你有遇到什么样的技术难题？

吐槽吐槽：阿里的面试更倾向于实用性，基本是从各种场景出发，来给你一个预期，让你来解决问题，那么在解决问题的过程中，对于各种知识的应用就是亮点了。

最后的最后：

有需要的可能找我内推，我们是阿里国际化中台事业部，新零售行业的跨境电商平台。新业务，新起点，有兴趣私我，或者直接留言啦