写在前面：     最终拿到了虾皮和阿里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的值更新为BCAS的缺点：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.你有遇到什么样的技术难题？       吐槽吐槽：阿里的面试更倾向于实用性，基本是从各种场景出发，来给你一个预期，让你来解决问题，那么在解决问题的过程中，对于各种知识的应用就是亮点了。   最后的最后：     有需要的可能找我内推，我们是阿里国际化中台事业部，新零售行业的跨境电商平台。新业务，新起点，有兴趣私我，或者直接留言啦