一、面试概况
今天是之前面美团java研发凉之后的,美团后端捞起面试,我之前一直是觉得自我感觉良好的,【感觉技术面以及四门专业课=====从来不虚】,结果今天感觉非常的知足,不是说的笔试和面试怎么杨吧,就是我在今天这场面试中,积攒到了很多经验,找到了自身的不足,应该思考的地方,面试的要点,让我很是受益,所以抓紧做一个笔记。
二、面试-笔试
两个算法: 一个是二叉树的先序遍历【做出来了】 合并两个有序数组【也做出来了】
三、技术面
3.1 Redis【一直在干redis连环炮】
3.2 说一下redis为什么快?
我说基于内存,基于单线程,然后网络请求有IO多路复用所以很快。 1、完全基于内存 2、数据结构简单 3、采用单线程,避免了不必要的上下文切换和竞争条件,也不存在多进程或者多线程导致的切换而消耗 CPU,不用去考虑各种锁的问题,不存在加锁释放锁操作,没有因为可能出现死锁而导致的性能消耗; 4、使用多路 I/O 复用模型,非阻塞 IO;
3.3 redis如何保证数据的一致性?
我说了个集群 分区数据同步一致性,因为真的想不到了
3.4 redis的锁机制
1.Redis中可以使用SETNX命令实现分布式锁 当且仅当 key 不存在,将 key 的值设为 value。 若给定的 key 已经存在,则 SETNX 不做任何动作 2.RedLock 安全特性:互斥访问,即永远只有一个 client 能拿到锁 避免死锁:最终 client 都可能拿到锁,不会出现死锁的情况,即使原本锁住某资源的 client crash 了或者出现了网络分区 容错性:只要大部分 Redis 节点存活就可以正常提供服务 3.redission Redisson是一个高级的分布式协调Redis客服端,能帮助用户在分布式环境中轻松实现一些Java的对象 (Bloom filter, BitSet, Set, SetMultimap, ScoredSortedSet, SortedSet, Map, ConcurrentMap, List, ListMultimap, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, ReadWriteLock, AtomicLong, CountDownLatch, Publish / Subscribe, HyperLogLog)。
3.5 redis的事务【redis 事务不保证原子性,不支持回滚】
Redis 事务的本质是通过MULTI、EXEC、WATCH等一组命令的集合。事务支持一次执行多个命令,一个事务中所有命令都会被序列化。在事务执行过程,会按照顺序 串行化执行队列中的命令,其他客户端提交的命令请求不会插入到事务执行命令序列中 1.单独的隔离操作:事务中的所有命令会被序列化、按顺序执行,在执行的过程中不会被其他客户端发送来的命令打断 2.没有隔离级别的概念:队列中的命令在事务没有被提交之前不会被实际执行 3.不保证原子性:redis中的一个事务中如果存在命令执行失败,那么其他命令依然会被执行,没有回滚机制 总结说:redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令 1.事务开始 MULTI 2.命令入队 3.事务执行 EXEC
3.6 redis的五大数据类型
String,List,Set,Zset,Hash
3.7 redis的5大数据类型的使用场景
1.String 进行自增自减运算,从而实现计数器功能,很适合存储频繁读写的计数量 2.list: 可以通过lpush/rpush rpop/lpop 读取和写入消息,实现阻塞队列 3.Set 可以实现交集、并集等操作,从而实现共同好友,推荐等等功能 4.ZSet 可以实现有序性操作,从而实现排行榜等功能。
3.8 redis的list 与 set的区别?
3.9 redis的String底层怎么实现的?list、set,hash的底层怎么实现?
1.String的数据类型是由SDS【简单动态字符串】实现的,C语言的实现方式有专门用于保存字符串长度的变量,所以可以在O(1)时间内获得 2.链表是list的实现方式之一。当list包含了数量较多的元素,或者列表中包含的元素都是比较长的字符串时,Redis会使用链表作为实现List的底层实现。此链表是双向链表。 链表结构的特点是可以快速的在表头和表尾插入和删除元素,但查找复杂度高,是列表的底层实现之一 3.Hash:数组 + 链表(采用头插法解决冲突,不会像java语言的map一样转化为红黑树),redis会把kay、value封装成一个dictEntry的结构体(dictEntry的key为string类型,value是一个指针,指向一个redisObject对象(不像java语言一样把hashmap的key、value的具体值封装在一起)) 3.list底层实现:底层是链表,有两个list,一个是ziplist,字面意是压缩列表,另一个是quicklist,字面意是快速列表,在redis中直接使用的是quicklist. 4.set底层实现: Set是一个特殊的value为空的Hash 5.zset底层实现:Zset底层是一种跳表SkipList数据结构(跳表在原有的有序链表上面增加了多级索引,通过索引来实现快速查找,实质就是一种可以进行二分查找的
其实跳表主要是来替代平衡二叉树的,比起平衡树来说,跳表的实现要简单直观的多。 跳跃表(skiplist)是一种有序数据结构,它通过在每个节点中维持多个指向其他节点的指针,从而达到快速查找访问节点的目的。跳跃表是一种随机化的数据,跳跃表以有序的方式在层次化的链表中保存元素,效率和平衡树媲美 ——查找、删除、添加等操作都可以在O(logn)期望时间下完成
3.10 在使用场景中怎么区别 list 与 set ?
2.list: 可以通过lpush/rpush rpop/lpop 读取和写入消息,实现阻塞队列 3.Set 可以实现交集、并集等操作,从而实现共同好友,推荐等等功能 4.ZSet 可以实现有序性操作,从而实现排行榜等功能。
3.11 Redis的内存用完了?
1.Redis支持运行时通过命令动态修改内存大小 2.Redis的内存淘汰
3.12 redis的那些命令是原子性的?
3.13 RDB && AOF
RDB是在某个时间点将数据写入一个临时文件,持久化结束后,用这个临时文件替换上次持久化的文件,达到数据恢复。 优点:使用单独子进程来进行持久化,主进程不会进行任何IO操作,保证了redis的高性能 缺点:RDB是间隔一段时间进行持久化,如果持久化之间redis发生故障,会发生数据丢失。所以这种方式更适合数据要求不严谨的时候redis.conf
AOF:将“操作 + 数据”以格式化指令的方式追加到操作日志文件的尾部,在append操作返回后(已经写入到文件或者即将写入),才进行实际的数据变更,“日志文件”保存了历史所有的操作过程;当server需要数据恢复时,可以直接replay此日志文件,即可还原所有的操作过程。AOF相对可靠,它和mysql中bin.log、apache.log、zookeeper中txn-log简直异曲同工。AOF文件内容是字符串,非常容易阅读和解析。 AOF默认关闭,开启方法,修改配置文件reds.conf: appendonly yes
优点:可以保持更高的数据完整性,如果设置追加file的时间是1s,如果redis发生故障,最多会丢失1s的数据;且如果日志写入不完整支持redis-check-aof来进行日志修复;。AOF的特性决定了它相对比较安全,如果你期望数据更少的丢失,那么可以采用AOF模式 缺点:AOF文件比RDB文件大,且恢复速度慢。
四、Mysql
4.1 说一下Innodb引擎
简单
4.2 说一下mysql的锁机制
悲观锁 在对任意记录进行修改前,先尝试为该记录加上排他锁(exclusive locking) 如果加锁失败,说明该记录正在被修改,那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。 如果成功加锁,那么就可以对记录做修改,事务完成后就会解锁了。 其间如果有其他对该记录做修改或加排他锁的操作,都会等待我们解锁或直接抛出异常。
优点和缺点 优点:安全 缺点:悲观锁实际上是采取了“先取锁在访问”的策略,为数据的处理安全提供了保证,但是在效率方面,由于额外的加锁机制产生了额外的开销,并且增加了死锁的机会。并且降低了并发性;当一个事物所以一行数据的时候,其他事物必须等待该事务提交之后,才能操作这行数据。
乐观锁 相对悲观锁而言,乐观锁假设认为数据一般情况下不会造成冲突,所以在数据进行提交更新的时候,才会正式对数据的冲突与否进行检测,如果发现冲突了,则让返回用户错误的信息,让用户决定如何去做。 相对于悲观锁,在对数据库进行处理的时候,乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本
乐观锁的优点和缺点 乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的,因此尽可能直接做下去,直到提交的时候才去锁定,所以不会产生任何锁和死锁。但如果直接简单这么做,还是有可能会遇到不可预期的结果,例如两个事务都读取了数据库的某一行,经过修改以后写回数据库,这时就遇到了问题。
4.3 说一下如何排查慢SQL
1.mysql默认不开启慢SQL日志,检查是否开启了 慢查询日志 :
show variables like '%slow_query_log%' ;
2.开启慢SQL
/etc/my.cnf 中追加配置:vi /etc/my.cnf
[mysqld]
slow_query_log=1
slow_query_log_file=/var/lib/mysql/localhost-slow.log
3.查询超过阀值的SQL
show global status like '%slow_queries%' ;
4.慢查询的sql被记录在了日志中,因此可以通过日志 查看具体的慢SQL。
cat /var/lib/mysql/localhost-slow.log
5.通过explain分析sql语句,例:
explain select name from tablex where a = '1';
4.4 说一下mysql悲观锁与乐观锁的使用场景?
悲观锁:比较适合写入操作比较频繁的场景,如果出现大量的读取操作,每次读取的时候都会进行加锁,这样会增加大量的锁的开销,降低了系统的吞吐量。 乐观锁:比较适合读取操作比较频繁的场景,如果出现大量的写入操作,数据发生冲突的可能性就会增大,为了保证数据的一致性,应用层需要不断的重新获取数据,这样会增加大量的查询操作,降低了系统的吞吐量。 总结:两种所各有优缺点,读取频繁使用乐观锁,写入频繁使用悲观锁。
五、JVM
5.1 说一下在什么情况下,对象会进入老年代?
1.大对象 2.长期存活的对象 s0 s1 15岁以后【只答出来这个】
5.2 说一下为什么 s0区 = s1区
没答出来
5.3 如果java程序CPU过高,如何排查????
进程====》定位线程 一般java应用cpu过高基本上是因为 1.程序计算比较密集 2.程序死循环 3.程序逻请求堵塞 4.IO读写太高
1、先通过top命令找到消耗cpu很高的进程id假设是123
2、执行top -p 123单独监控该进程
3、在第2步的监控界面输入H,获取当前进程下的所有线程信息
4、找到消耗cpu特别高的线程编号,假设是123
5、执行jstack 123456对当前的进程做 jmap -dump,输出所有的线程信息
6 将第4步得到的线程编号11354转成16进制是0x7b
7 根据第6步得到的0x7b在第5步的线程信息里面去找对应线程内容
8 解读线程信息,定位具体代码位置
定位到cpu过高是IO读写太高 ,接下来就是找开发人员确认这段代码是否可以优化
5.4 Java OOM问题如何排查????
1.查看java 进程/线程对系统的占用情况,如 top -pid
2.jstack pid > file.log 通过jstack 把该进程的所有线程堆栈打印到file.log中
3.jmap -heap 进程/线程号 显示堆内存信息
4.jmap -dump 生成堆内存转储快照
5.加载对比 堆文件,发现 对象增多,初步定位到问题
六、Java
在我非常擅长的java这一块,只问了一个volitize关键字 我说,是一个关键字,只能作用在变量上,保证可见性,防止指令重排,不保证原子性 面试官反问:除了可见性,还能保证什么????
七、反问
我说我自己今天表现不是很好,问问面试官对我有什么地方改进? 面试官:说对我期望特别高,看到我简历说我会的技术栈很全,所以问我的时候并没有刁难我,不要为了面试而面试,而是选择有思考的让我去考虑问题。 最后感谢了面试官,因为真的收获很大,也知道了在学习时候如何如避免形成刻板思路,多思考!!!
|