二、MySQL数据库为什么要用innodb：1、支持事务；2、实现了MySQL的mvcc；3、支持行级锁；
三、启动springboot的那个注解：
默认扫描包路径：main方法所在的类下面的所有包和子包
四、@RequestParam 怎么回事，这个居然都忘记了，不过也不能说忘记，因为确实不怎么用，因为这个一般都是get请求的，而我一般都是post，request请求的：SpringCloud
@PathVariable：这个真的没有用过，什么“映射 URL 绑定的占位符”，不懂；
五、redis的优点：
1）基于内存，操作速度快；
2）丰富的数据类型，有STRING,LIST,HASH,SET,SORTEDSET，二那个什么mach的什么什么只支持单一的数据类型STRING；
3）支持事务；
4）原子性操作；
5）支持持久化策略：AOF和RDB
缺点：数据不一致；代码维护成本
六、使用redis应该注意什么，其实就是问 缓存穿透、缓存雪崩、缓存击穿；接着问这三个是怎么回事，以及各自的解决方法；我回答了缓存穿透的解决方法：那个布隆过滤bitmap的厉害之处，对方接着问，如果那个bitmap的hashcode一样（即hash冲突了，怎么解决），我回答了equal方法，对方说不是这样子，然后我就被问死了。
你有什么解决方案来防止缓存雪崩？
1、加锁排队 key： whiltList value：1000w个uid 指定setNx whiltList value nullValue
mutex互斥锁解决，Redis的SETNX去set一个mutex key，
当操作返回成功时，再进行load db的操作并回设缓存；
否则，就重试整个get缓存的方法
2、数据预热
缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，
先查询数据库，然后再将数据缓存的问题!用户直接查询事先被预热的缓存数据!
可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的key
3、双层缓存策略
C1为原始缓存，C2为拷贝缓存，C1失效时，可以访问C2，C1缓存失效时间设置为短期，C2设置为长期。
4、定时更新缓存策略
失效性要求不高的缓存，容器启动初始化加载，采用定时任务更新或移除缓存
5、设置不同的过期时间，让缓存失效的时间点尽量均匀
缓存穿透：
1、缓存空值
如果一个查询返回的数据为空(不管是数据不 存在，还是系统故障)我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 通过这个直接设置的默认值存放到缓存，这样第二次到缓冲中获取就有值了，而不会继续访问数据库
2、采用布隆过滤器BloomFilter 优势占用内存空间很小，bit存储。性能特别高。
将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个
bitmap 拦截掉，从而避免了对底层存储系统的查询压力
七、如果给7亿数据你，你怎么处理这些数据；我回答了集群，多主多从，一主对多从，读写分离的架构模式；然后对方问在多主的情况下，这7亿数据，你应该怎么分配到这若干台主机上面，（中间配一个Nginx代理服务器，利用反向代理，结合一定的hash算法，分发到这若干台主机上面），如果业务突然要求要额外导3亿数据进来，允许你增加机器，比如说增加了3台，你怎么很好地结合本来的七亿数据；1）hashmap的rehash原理，将这10亿数据重新hash分配（时间充足，建议）；2）先把这3亿数据放在这三个机器，然后到时候来两边的机器都重新查一遍（时间不充足）；
八、vue的特点，以及优缺点
九、什么时候用到多线程；谈谈你对锁的理解（我主要是回答了synchronized关键字，和readwritelock接口），然后那个面试官就说能否用synchronized实现读写锁功能，看我疑惑了一下，说不会很正常，这个有点偏门了，大部分人都不会；
十、wait状态和runnable状态之间是什么？我当时很懵逼，不应该是写业务代码吗？
十一、请设计一下电商秒杀系统的实现方式？
十二、springmvc如何实现异步响应？
十三、MySQL根据一组id查结果如何保证顺序？redis如何批量查询多个key？
十四、如何实现分布式锁？（SETNX）
十五、cron表达式 0/15 * * * *？如何解释
十六、至少列出三种rpc方式，并具体到具体所使用的场景
十七、乐观锁的实现方式（版本号，cas，自旋，ABA问题）
十八、try代码块中有return,又有finally代码块：先执行finally代码块里面的，再执行try代码块里面的return语句
十九、关于JAVA中String类以形参传递到函数里面，修改后外面引用不能获取到更改后的值
首先得明白为什么会有线程安全这个问题，之所以要考虑线程安全，是因为变量是可变的，可以被其他线程修改。如果这种情况发生了，就是线程不安全了。
如果这个变量本身都不可以变了，也就谈不上那个什么线程安全不安全了，或者说肯定是线程安全的。比如String，因为根本改不了啊。
二、redis为什么这么快：
1）完全基于内存操作；
2）数据结构数据操作简单，也对数据结构进行了专门的优化；
3）采用单线程，避免了不必要的上下文切换以及竞争条件（采用单线程操作就已经很快了，所以就不必要采用多线程了）；
4）采用了多路复用IO
四、Redis 内存淘汰机制：在redis.conf里面配：maxmemory <bytes>；
默认：当内存使用达到阈值的时候，所有引起申请内存的命令会报错
在带有过期时间的键中选择最近最少使用的。（推荐）
在所有的键中选择最近最少使用的。（不区分是否携带过期时间）（一般推荐）
六、乐观锁、悲观锁：我们平时看到的：synchronized 以及 就是悲观锁ReentrantLock
乐观锁的版本号方法：当我们要从数据库中读取数据的时候，同时把这个version字段也读出来，如果要对读出来的数据进行更新后写回数据库，则需要将version加1，同时将新的数据与新的version更新到数据表中，且必须在更新的时候同时检查目前数据库里version值 是不是之前的那个version，如果是，则正常更新。如果不是，则更新失败，说明在这个过程中有其它的进程去更新过数据了。
七、分布式锁过程当中，怎么解决setnx,setex的问题：1）用lua脚本，里面就是原子性了；2）后来的新本来setnx，setex可以用一条命令来替代了；
八、你知道Redis读写分离是怎么做数据同步的吗（数据的一致性）
redis2.8版本之前使用旧版复制功能SYNC SYNC是一个非常耗费资源的操作 主服务器需要执行BGSAVE命令来生成RDB文件，这个生成操作会耗费主服务器大量的的 CPU、内存和磁盘读写资源 主服务器将RDB文件发送给从服务器，这个发送操作会耗费主从服务器大量的网络带宽和流 量，并对主服务器响应命令 请求的时间产生影响：接收到RDB文件的从服务器在载入文件的过程是阻塞的，无法处理命令 请求 2.8之后使用PSYNC PSYNC命令具有完整重同步（full resynchronization）和部分重同步（partial resynchronization1）两 种模式 部分重同步功能由以下三个部分构成： 主服务的复制偏移量（replication offset）和从服务器的复制偏移量 主服务器的复制积压缓冲区（replication backlog）,默认大小为1M 服务器的运行ID(run ID),用于存储服务器标识，如从服务器断线重新连接，取到主服务器 的运行ID与重接后的主服务器运行ID进行对比，从而判断是执行部分重同步还是执行完 整重同步
end!