java中级程序员的几个面试题

1.G1有哪几种GC？什么时候出发full gc？

参考这篇
G1旨在取代CMS，一个特点就是可以指定STW时间，参数是-xx:MaxGCPauseMillis=100。
G1有两种回收算法：年轻代是复制算法，老年代是标记清除算法。
G1采用分区思路，分区有大有小，需要注意的是年轻代，老年代并不是物理上完全区分的，而是在分区里面任意占用。

G1有两种GC，Young GC和oldGC，当所有eden分区满了就会进行Young GC，存活下来的都拷贝到Survivor区，并根据年龄晋升到老年代（这个特点跟具体回收器无关），实现是维护一个card table，就是对象的映射，Card中对象的引用发生改变时，标记成dirty，Young GC的时候只需要扫描状态是dirty的card。每一个分区都有一个RSet，记录这谁引用了我的对象，
当堆大小超过一定比例，便会执行老年代收集并会顺便触发年轻代收集。

当使用空间不够时，会执行一次STW式的、单线程的Full GC。Full GC会对整堆做标记清除和压缩，最后将只包含纯粹的存活对象。
G1在以下场景中会触发Full GC，同时会在日志中记录to-space-exhausted以及Evacuation Failure
从年轻代分区拷贝存活对象时，无法找到可用的空闲分区
从老年代分区转移存活对象时，无法找到可用的空闲分区
分配巨型对象时在老年代无法找到足够的连续分区

2.什么是内存泄露，如何排查？

内存泄露就是不需要再被使用的对象的内存不能被回收。比如
Object object;
public void method1(){
object = new Object();
这里的object实例，其实我们期望它只作用于method1()方法中，而且其他地方不会用到。
}
我们常见的内存泄露一般就是后面不需要用到了，但是我们没有手动赋值null，导致有个时间差没有被回收，可能引起不必要的oom。
//…对v的操作
vector = null;//及时赋null，否则在跟v无关的操作时间内还浪费空间
//…与v无关的其他操作
内存泄露最终导致内存溢出也就是oom。
排查用jmap，参考这篇
jmap -histo:live PID| head -7
如果还无法定位出用dump
jmap -dump:live,format=b,file=heap.hprof PID
在Windows，cmd使用jvisualvm，然后文件->装入。可以查看详细内存使用情况。

3.JVM内存管理以及对象分配全过程

参考这篇
内存管理分为：
1.内存区域分布，也就是堆，方法区这写。
2.对象创建以及对象的内存布局（对象头，实例数据，对齐填充）
3.垃圾回收。

1.内存区域分成 堆存放对象，虚拟机栈存放方法的局部变量。本地方法栈本地方法的局部变量。程序计数器存放当前线程运行到哪一行。方法区存放类信息，静态变量，常量。直接内存，NIO用到的。

2.对象创建步骤是 类加载，分配内存，值初始化成0，填充对象头数据比如GC年龄，hash值，执行初始化方法。

4.redis持久化RDB和AOF优缺点。

RDB持久化就是每个一段时间保存当前内存中的数据。
AOF持久化就是记录服务器执行所有写的操作命令，通过重新执行命令还原数据。
可以同时使用AOF和RDB，但会优先用AOF恢复，因为RDB保存有个时间差，AOF时间差教少，数据更完整。

RDB优缺点：
优点：保存了某个时间点的数据情况，适合备份，灾难恢复，而且只有一个文件，内存非常紧凑，并且是通过fork一个子进程运行RDB程序，RDB在大数据量下比AOF快。
缺点：数据丢失可能比较严重，因为通常是分钟级保存一次。因为是fork子进程如果数据量大的话，会导致服务器停止时间过长。

AOF优缺点：
优点：数据丢失很少，一般是1秒就保存一次，最多丢失1秒数据。写入数据时只是追加，如果写入了不完整的命令，redis-chckout-aof工具可以修复这个问题。当AOF文件过大时，会自动进行重写，说是重写其实是对命令进行优化，比如对一个集合进行很多操作，旧的aof保存所以操作，重写时只要保存最终集合状态的命令就可以了，重写时仍然会往旧的AOF追加命令，重新时的命令会保存到内存，然后写入到新的文件，等到新的文件完成后才会停止往旧的AOF追加。
缺点：AOF体积通常大于RDB，AOF效率较低。

5.redis集群分片原理

只有主从模式时，如果key很多会导致服务器压力比较大，所以搞集群进行数据分片，
redis有16384个hash槽需要自己配置每台机器对应的范围，通过一致性hash进行查询的，每个节点都会保存每个槽的信息，如果这个下标刚好是自己的就直接返回结果，否则进行重定向，请求到这个槽记录的ip:port那个redis，当一条命令需要处理多个key，这些key分布到不同的节点，会报错，所以redis提供了hashtags，即只对一个key的某个长度进行计算。

6.redis内存淘汰策略和淘汰算法

淘汰策略有3种：
定时删除：设置过期时间的时候，创建一个定时器，当时间到了，就删除。（太多定时器，不现实）
惰性删除：当查询这个key的时候才判断是否过期了，是才从内存删除。（浪费内存，如果过期的没有被访问相当于内存泄露了）
定期删除：每个一段时间检查，删除过期的key，删除多少怎么删除需要具体算法决定。（常用，需要调整好检查时间以及删除多少key）
淘汰算法参考这篇
删除不是删除所有过期的key，因为如果遍历所有的key那redis肯定要忙死了，不能提供服务，所以一般是选取一部分样本遍历，删除最适合删除的key（根据淘汰算法），一直循环，知道内存小于最大使用内存。

7.redis的zset底层原理

关于数据结构和内部编码参考这篇
zset的编码可以是 ziplist或者是dict+skiplist，之所以选择字典+跳表组合是因为字典查找块，但是范围查找慢，跳表可以范围查询，但是查找慢，所以通过这两种组合。

ziplist：参考这篇
之所以叫压缩，是相较于数组来说，数组里面的每个元素占用空间都是一样的，如果存的元素有大有小就会很浪费空间，所以压缩列表是一种紧凑的数据结构。
里面元素保存了上一个节点的长度，之所以是上一个节点是因为redis是从尾部进行遍历，然后保存了当前节点的长度和数据类型，还有当前节点的内容。
压缩列表有个连锁更新问题，比如新插入了一个元素，e2要记录e1的长度原来e2是用1个字节记录现在新元素需要5个字节记录，也就是说e2元素的长度变了，导致e3要更新e2的长度,e4要更新e3的。。一直更新到en，这种现象就叫连锁更新。删除元素也可能出现连锁更新，比如 e1->e2->e3，e3本来用1个字节记录e2长度，现在e2删除，e1比较大，e3就要用5个字节记录，导致e3后面的元素全部要更新。
尽管连锁更新的复杂度较高，但它真正造成性能问题的几率是很低的，因为出现的条件比较偶然。

dict:相当于java中的hashmap，原理一样。
skiplist:

查找的时候先从高层查找，然后在往下一层找，

8.redis位图

位图就是节约内存用的，比如要记录一年的签到记录，如果使用K-V结构浪费很多空间，我们直接创建 byte[365]就可以了，下标就是天，1代表签到0代表没签到。命令是
setbit 表名 下标 值