首页 > 社招两年,快手,虾皮阿里面经
头像
狗子b
编辑于 2021-02-03 23:51
+ 关注

社招两年,快手,虾皮阿里面经

写在前面:

最终拿到了虾皮和阿里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.你有遇到什么样的技术难题?


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

最后的最后:

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

更多模拟面试

全部评论

(18) 回帖
加载中...
话题 回帖

推荐话题

相关热帖

历年真题 真题热练榜 24小时
技术(软件)/信息技术类
查看全部

近期精华帖

热门推荐