目录

一、HashMap和CocurrentHashMap

说一下你对HashMap的理解；他的底层结构是什么样的；

一个数据是怎么存到，map里面的；

怎么可以让HashMap的碰撞变小；

为什么不能用可变类型做键值呢；

链表什么时候转成红黑树；为什么要转成红黑树；

红黑树是什么样的，他的结构是什么样的；他还要其他什么特征吗；

CocurrentHashMap历史变化、数据结构及原理

为什么1.7到1.8要换一种方式

分段锁是的底层怎么实现的；

他的继承结构；

自旋锁是怎么实现的

如果俩个key都在同一个分段上面，是怎么保证安全的；

CAS的实现原理

二、锁：

java里面的锁常用的都有哪些；

synchronized修饰一个静态类和静态方法和修饰一个非静态方法有什么区别吗？

ReentrantLock的实现原理

讲讲乐观锁和悲观锁；

三、线程池：

线程池的原理；线程池它里面的主要参数有哪些；

keepAliveTime是什么；

回收的话回收到多少个线程呢；

线程池是怎么实现一个线程复用的；

初始化线程池时线程数的选择

说说线程池的拒绝策略

五种线程池的使用场景

线程池的关闭

线程池都有哪几种工作队列

execute和submit的区别？

四、jvm及GC：

jvm垃圾回收的流程；哪些对象会被认为是垃圾；有一个对象A它有一个属性是B，B这个对象他又有一个属性是A，这个对象最终会不会被认为是垃圾;

GC root哪些对象会被认为是root；

jvm里面有一个存储虚拟s1和s2

什么样的数据会往老年代里面迁移呢；

如果老年代内存也不够用了怎么办呢；

fullGC的时候会有什么现象吗；有没有遇到到fullGC的时候影响业务的场景；

CMS收集器

G1收集器：

五、数据库：

接触过哪些数据库；

oracle和mysql分页的区别；oracle分页的原理；

什么情况要加索引,哪些字段上适合加索引；

使用索引的优缺点？

mycat会用吗；平时会自己弄分库分表吗；什么时候需要分库什么时候需要分表；

你们现在的数据量大吗；是怎么进行拆分存储的；数据库是分库的对吧；他的分库的规则是什么样的；

读锁和写锁的实现方式，加了读锁，其他资源能不能读，加了写锁其他资源能不能读；

六、redis：

redis是什么语言开发的；

redis底层的实现原理有去研究过吗；为什么redis的性能能达到这么快呢；

redis里面有个string，一个字符串类型的值能存储最大容量是多少；你知道他的底层是怎么实现的；

redis的keys为什么影响性能,redis时间复杂度是O(n)的命令；

一般用redis都做什么；

什么是redis的缓存穿透；什么是缓存雪崩；怎么解决这些问题；缓存穿透不通过ip过滤，最简单的方式怎么解决；

redis 和 memcached 的区别：

Redis 哈希槽的概念

redis 设置过期时间；

redis有做集群吗；怎么做集群的；你在项目中还遇到什么问题吗；

redis持久化问题；会有数据损失吗，开启aof的持久化吗；

Redis Sentinel的工作流程

如何解决 Redis 的并发竞争 Key 问题

cps是多少；一秒钟处理多少；

分布式锁的实现方式；有哪些常见的数据分布式算法，比如说现在部署了3个redis，里面的内存是不一样的，怎么保证有一个内存回落到固定的一个redis实例上面的分布式算法；一致性hash算法相较于普通hash算法有什么优势；

你对sentinel hystrix有用过吗；你们微服务有用sentinel 吗

说一下你们的熔断是怎么做的

你认为什么时候是不可用的

sentinel hystrix的区别

七、MQ:

消息会有消费失败的情况吗;消费失败系统怎么处理；

kafka的底层是怎么实现的；怎么可以达到这么高的吞吐量

你们用kafka有遇到什么问题吗；

如果保证一个消息消费他是有序的怎么做

kafka和activemq和ribbitmq的区别

如果消费端异常，后续的操作流程是什么；

死信队列如果消息失败可以放；mq的更新频路是怎么设置的；

八、jdk1.8有什么新特性；

一、HashMap和CocurrentHashMap

说一下你对HashMap的理解;他的底层结构是什么样的；一个数据是怎么存到，map里面的；怎么可以让HashMap的碰撞变小；为什么不能用可变类型做键值呢；链表为什么要转成红黑树；什么时候转成红黑树；红黑树是什么样的；红黑树的具体算法可以讲讲吗；CocurrentHashMap历史变化、数据结构及原理；为什么1.7到1.8要换一种方式;分段锁是的底层怎么实现的；他的继承结构；自旋锁是怎么实现的;如果俩个key都在同一个分段上面，是怎么保证安全的；CAS的实现原理;

说一下你对HashMap的理解；他的底层结构是什么样的；

jdk7之前底层使用的是数组+链表的形式，1.8之后改成了数据加链表加红黑二叉树，提高查询性能，

一个数据是怎么存到，map里面的；

1.首先创建hashmap，默认大小是16，负载因子是0.75，我们可以去指定他的长度size，如果自己传入初始大小k，初始化大小为 大于k的 2的整数次方。那么为什么2的整数次方，例如如果传10，大小为16。

2.然后我们进行一个插入，首先他会对key取一个hash值，是32位的int值，让他的高16位和低16位进行一个与或运算，原因的是因为后16位有可能是相同的 为了使我们hash的值分布的更加均匀，并且使用位运算也非常高效 。

源码里面就把散列值和（（数组的长度-1 ）因为-1之后他的地位全都是1高位都为0这种形式）做了与运算 算出数组的下标。之所以要做是因为int值的范围是 -2的31次方-1到2的32次方 前后加起来大概与40亿的映射空间 但问题是一个40亿长度的数组 内存是放不下的。

3.之后我们把hashCode的节点组装成一个entry节点 把这个entry节点存储到数组下表里面  存储的时候首先会判断一下这个数组的下标是不是有值 如果说有值得话  他首先去判断这个key的值是不是是相等的 如果是相等的 说明我们是相同的一个值 那我们就要用现在的值替换掉原来的值如果是不相等的 那就使用链表的形式将他串联起来。存储之后链表也会做一个判断如果说链表他是大于8的 我们会把它转化成一个红黑二叉树进行排列。

这里有一个jdk7和jdk8的区别

1. 数组+链表改成了数组+链表或红黑树；
2. 链表的插入方式从头插法改成了尾插法，原因是因为我们在非线程安全下使用hashmap的时候会出现一个死循环的问题 这个问题在1.8之后进行了一个修复.
3. 扩容的时候1.7需要对原数组中的元素进行重新hash定位在新数组的位置，1.8采用更简单的判断逻辑，位置不变或索引+旧容量大小；
4. 在插入时，1.7先判断是否需要扩容，再插入，1.8先进行插入，插入完成再判断是否需要扩容；

怎么可以让HashMap的碰撞变小；

算法让他分布的更均匀 位运算 扩容

为什么不能用可变类型做键值呢；

因为可变类型作为key，如果修改会造成数据无法找到。

链表什么时候转成红黑树；为什么要转成红黑树；

我们在jdk1.8使用了红黑树，原因是因为我们在发生hash碰撞的时候，我们会把数据按照链表的形式把他插入进去，那么这个时候因为我们链表只能从头结点进行一个遍历，那么他的一个时间复杂度就On，非常影响性能，所以我们当他大于2三次方8的时候就会转成红黑树；原因是使用红黑二叉树之后，当我们在查询数据的时候复杂度就会降为O1，可以大大的提高我们的性能

红黑树是什么样的，他的结构是什么样的；他还要其他什么特征吗；

他的结构的话我们平常会像这种平衡二叉树来维护他，但是平衡二叉树可能说是我每插入一个节点，他就要去维护这种情况，比较频繁，就有了红黑二叉树这种红黑节点相互交替，他有四个规则，

CocurrentHashMap历史变化、数据结构及原理

在并发编程里面使用的CocurrentHashMap，在1.7我们使用sengment分段锁，每一次key进来之后，他都会判断你这个key是属于哪一个分段里面的，从而拿到sengment。锁主要是加在链表上的，因为链表会导致我们线程安全的问题，1.8之后我们将锁改成了CAS+synchronized，解决分段锁的弊端。

为什么1.7到1.8要换一种方式

之所以改锁机制是因为sengment分段锁他可以设置，但是他默认是16段，这个时候我们的并发量就会有一个限制，包括我们需要去估sengment的个数，如果估少了，就会导致锁的空闲，估大了会导致锁的一些竞争，而且一旦初始化以后，它是不可以扩容的，所以之后改成了自旋锁，大大提高了性能。

分段锁是的底层怎么实现的；

分段锁底层维护了一个数组，我们默认的话是16段，每一个段就相当于一把锁，然后最大的并发量可能到达16；

他的继承结构；

它继承了ReentrantLock，然后ReentrantLock继承了AQS(AbstractQueuedSynchronizer)

自旋锁是怎么实现的

思想是给 table的每一个下标都加锁，也就是当对下标进行操作时都会加锁（CAS+Synchronize）。ConcurrentHashMap 成员变量使用 volatile 修饰，免除了指令重排序，同时保证内存可见性，另外使用 CAS操作和 synchronized结合实现赋值操作，多线程操作只会锁住当前操作索引的节点。

如果俩个key都在同一个分段上面，是怎么保证安全的；

CAS的实现原理

CAS其实就是CompareAndSwap首先他会传入一个值还有他的地址，然后进行一个CAS的判断，当前的值与我们现在的值进行比较，如果说一样的话，那我再会进行一个数据的插入，当前的第三个值插入进去，如果不相同从新获取值，然后进行修改，进行插入，这个值可能会有一个ABA的问题，所以每次拿到值以后，会给他加一个版本号，然后进行比较插入的。

二、锁：

java里面的锁常用的都有哪些；synchronize修饰一个静态类和静态方法和修饰一个非静态方法有什么区别吗；ReentrantLock的实现原理；讲讲乐观锁和悲观锁；

java里面的锁常用的都有哪些；

常用的有synchronized（Object）、ReentrantLock（可重用锁）这些；

synchronized修饰一个静态类和静态方法和修饰一个非静态方法有什么区别吗？

Synchronized修饰非静态方法，实际上是对调用该方法的对象加锁，俗称“对象锁”。

Synchronized修饰静态方法，实际上是对该类对象加锁，俗称“类锁”。

ReentrantLock的实现原理

ReentrantLock的使用

Lock lock = new ReentranLock();
lock.lock();
try{//do something
}finally{lock.unlock();
}

ReentrantLock实现了Lock接口，加锁和解锁都需要显式写出，注意一定要在适当时候unlock。

和synchronized相比，ReentrantLock用起来会复杂一些。在基本的加锁和解锁上，两者是一样的，所以无特殊情况下，推荐使用synchronized。ReentrantLock的优势在于它更灵活、更强大，增加了轮训、超时、中断等高级功能。

ReentrantLock的原理

公平锁和非公平锁

public ReentrantLock() {sync = new NonfairSync();
}public ReentrantLock(boolean fair) {sync = fair ? new FairSync() : new NonfairSync();
}

ReentrantLock的内部类Sync继承了AQS，分为公平锁FairSync和非公平锁NonfairSync。

• 公平锁：线程获取锁的顺序和调用lock的顺序一样，FIFO；
• 非公平锁：线程获取锁的顺序和调用lock的顺序无关，全凭运气。

ReentrantLock默认使用非公平锁是基于性能考虑，公平锁为了保证线程规规矩矩地排队，需要增加阻塞和唤醒的时间开销。如果直接插队获取非公平锁，跳过了对队列的处理，速度会更快。

讲讲乐观锁和悲观锁；

乐观锁 ：总是认为不会产生并发问题，每次去取数据的时候总认为不会有其他线程对数据进行修改，因此不会上锁，但是在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用版本号机制或CAS操作实现

version方式： 

一般是在数据表中加上一个数据版本号version字段，表示数据被修改的次数，当数据被修改时，version值会加一。当线程A要更新数据值时，在读取数据的同时也会读取version值，在提交更新时，若刚才读取到的version值为当前数据库中的version值相等时才更新，否则重试更新操作，直到更新成功。

update table set x=x+1, version=version+1 where id=#{id} and version=#{version};  

CAS操作方式： 

即compare and swap 或者 compare and set，涉及到三个操作数，数据所在的内存值，预期值，新值。当需要更新时，判断当前内存值与之前取到的值是否相等，若相等，则用新值更新，若失败则重试，一般情况下是一个自旋操作，即不断的重试。 

悲观锁：总是假设最坏的情况，每次取数据时都认为其他线程会修改，所以都会加锁（读锁、写锁、行锁等），当其他线程想要访问数据时，都需要阻塞挂起。可以依靠数据库实现，如行锁、读锁和写锁等，都是在操作之前加锁，在Java中，synchronized的思想也是悲观锁

适用场景 
悲观锁：比较适合写入操作比较频繁的场景，如果出现大量的读取操作，每次读取的时候都会进行加锁，这样会增加大量的锁的开销，降低了系统的吞吐量。 
乐观锁：比较适合读取操作比较频繁的场景，如果出现大量的写入操作，数据发生冲突的可能性就会增大，为了保证数据的一致性，应用层需要不断的重新获取数据，这样会增加大量的查询操作，降低了系统的吞吐量。 
总结：两种所各有优缺点，读取频繁使用乐观锁，写入频繁使用悲观锁。

三、线程池：

线程池的原理；线程池它里面的主要参数有哪些；keepAliveTime是什么；回收的话回收到多少个线程呢；线程池是怎么实现一个线程复用的；初始化线程池时线程数的选择；说说线程池的拒绝策略；五种线程池的使用场景；线程池的关闭；线程池都有哪几种工作队列;execute和submit的区别;

线程池的原理；线程池它里面的主要参数有哪些；

public ThreadPoolExecutor(int corePoolSize,    //核心线程的数量int maximumPoolSize,    //最大线程数量long keepAliveTime,    //超出核心线程数量以外的线程空余存活时间TimeUnit unit,    //存活时间的单位BlockingQueue<Runnable> workQueue,    //保存待执行任务的队列ThreadFactory threadFactory,    //创建新线程使用的工厂RejectedExecutionHandler handler // 当任务无法执行时的处理器) {...}

线程池的参数有7个，首先根据系统的核数，设置核心线程数（corePoolSize），如果说核心线程数满了的话，会定义一个阻塞队列（workQueue），当阻塞队列满了的话，会继续去创建线程，所以这个时候有一个最大的线程数（maximumPoolSize），如果到达最大线程数之后的话，会有一个淘汰策略（handIer），进来之后的话，这个淘汰策略，我们会设置成lfu，还有就是我们线程池去连接的时候，他是有一个连接的超时时间（keepAliveTime）以及超时时间的单位（unit:keepAIiveTime），还有就是我们创建这个线程所用到的一个类加载器（threadFactory）是什么

keepAliveTime是什么；

调用线程池如果多长时间没有继续再去访问了，就会把线程回收进来

getTask 怎么使用 keepAliveTime
（1）首先也是一个自旋，当allowCoreThreadTimeout(运行空闲核心线程超时) 或 wc>corePoolSize(当前线程数量大于核心线程数量) 时，timed会标识为true，表示需要进行超时判断。
（2）当wc（当前工作者数量）大于 最大线程数 或 空闲线程的空闲时间大于keepAliveTime（timed && timeout），以及wc>1或（workQueue）任务队列为空时，会进入compareAndDecrementWorkerCount方法，对wc的值减1。
（3）当compareAndDecrementWorkerCount方法返回true时，则getTask方法会返回null，终止getTask方法的自旋。这时候回到runWorker方法，就会进入到processWorkerExit方法，进行销毁worker。

回收的话回收到多少个线程呢；

回收到核心的线程数；

线程池是怎么实现一个线程复用的；

线程创建的时候是怎么创建核心线程数的，当用完就会释放，其他线程进来就会在用，达到一个线程复用；

初始化线程池时线程数的选择

如果任务是IO密集型，一般线程数需要设置2倍CPU数以上，以此来尽量利用CPU资源。

如果任务是CPU密集型，一般线程数量只需要设置CPU数加1即可，更多的线程数也只能增加上下文切换，不能增加CPU利用率。

说说线程池的拒绝策略

    当请求任务不断的过来，而系统此时又处理不过来的时候，我们需要采取的策略是拒绝服务。RejectedExecutionHandler接口提供了拒绝任务处理的自定义方法的机会。在ThreadPoolExecutor中已经包含四种处理策略。

AbortPolicy策略：该策略会直接抛出异常，阻止系统正常工作。

CallerRunsPolicy 策略：只要线程池未关闭，该策略直接在调用者线程中，运行当前的被丢弃的任务。

DiscardOleddestPolicy策略： 该策略将丢弃最老的一个请求，也就是即将被执行的任务，并尝试再次提交当前任务。

DiscardPolicy策略：该策略默默的丢弃无法处理的任务，不予任何处理。

    除了JDK默认提供的四种拒绝策略，我们可以根据自己的业务需求去自定义拒绝策略，自定义的方式很简单，直接实现RejectedExecutionHandler接口即可。

五种线程池的使用场景

newSingleThreadExecutor：一个单线程的线程池，可以用于需要保证顺序执行的场景，并且只有一个线程在执行。

newFixedThreadPool：一个固定大小的线程池，可以用于已知并发压力的情况下，对线程数做限制。

newCachedThreadPool：一个可以无限扩大的线程池，比较适合处理执行时间比较小的任务。

newScheduledThreadPool：可以延时启动，定时启动的线程池，适用于需要多个后台线程执行周期任务的场景。

newWorkStealingPool：一个拥有多个任务队列的线程池，可以减少连接数，创建当前可用cpu数量的线程来并行执行。

线程池的关闭

关闭线程池可以调用shutdownNow和shutdown两个方法来实现

shutdownNow：对正在执行的任务全部发出interrupt()，停止执行，对还未开始执行的任务全部取消，并且返回还没开始的任务列表。

shutdown：当我们调用shutdown后，线程池将不再接受新的任务，但也不会去强制终止已经提交或者正在执行中的任务。

线程池都有哪几种工作队列

1、ArrayBlockingQueue

是一个基于数组结构的有界阻塞队列，此队列按 FIFO（先进先出）原则对元素进行排序。

2、LinkedBlockingQueue

一个基于链表结构的阻塞队列，此队列按FIFO （先进先出） 排序元素，吞吐量通常要高于ArrayBlockingQueue。静态工厂方法Executors.newFixedThreadPool()使用了这个队列

3、SynchronousQueue

一个不存储元素的阻塞队列。每个插入操作必须等到另一个线程调用移除操作，否则插入操作一直处于阻塞状态，吞吐量通常要高于LinkedBlockingQueue，静态工厂方法Executors.newCachedThreadPool使用了这个队列。

4、PriorityBlockingQueue

一个具有优先级的无限阻塞队列。

execute和submit的区别？

execute适用于不需要关注返回值的场景，只需要将线程丢到线程池中去执行就可以了。

submit方法适用于需要关注返回值的场景

四、jvm及GC：

jvm垃圾回收的流程；哪些对象会被认为是垃圾；有一个对象A它有一个属性是B，B这个对象他又有一个属性是A，这个对象最终会不会被认为是垃圾;GC root哪些对象会被认为是root；jvm里面有一个存储虚拟s1和s2；什么样的数据会往老年代里面迁移呢；如果老年代内存也不够用了怎么办呢；fullGC的时候会有什么现象吗；有没有遇到到fullGC的时候影响业务的场景；CMS收集器;G1收集器

jvm垃圾回收的流程；哪些对象会被认为是垃圾；有一个对象A它有一个属性是B，B这个对象他又有一个属性是A，这个对象最终会不会被认为是垃圾;

允许GC之后，开始查找那些允许被回收的（两个算法）-> 开始回收（四个算法）

第一步：那些对象是垃圾：

         1，引用计数法：通过对引用的遍历，找到对应的实例，让对应的实例计数加  1 ，如果引用取消，或者指向null，实例的引用减  1 。把找到的引用都遍历一遍之后，如果发现有对象实例的计数是0。那么这个对象 就是垃圾对象了。在通过垃圾回收算法对其进行 回收即可。

       缺点：想想一下，有两个类，互相引用，也就是A对象的实例（也就是对象的全局变量）是一个指向B对象的引用，B对象实例是一个指向A对象的引用。那么这两个对象的引用计数，永远不可能是0 。也就不可能对其进行回收了。

        2，可达性分析法：这个算法类似于树的遍历，学过数据结构的小伙伴应该会好理解。简单来说，按照一定的规则说明那些可以作为一个根节点（GC root），然后以这些根节点去访问其引用的对象，被访问的对象又会有其他对象的引用。想象一下，是不是像极了树的遍历。这个路径称作引用链，但凡是在引用链上的对象，都是可用的。注意，引用连的起始点都是GC root 哦。虽然有其他对象存在类似于引用链的结构，但是，起始点不是GC root的那一些，都是垃圾，可以被回收的。

一般情况下，都是使用的 可达性分析法去查找垃圾类实例。

GC root哪些对象会被认为是root；

         GC root的查找规则：java栈中的引用，方法区中的静态属性（静态变量 + 静态常量），方法区中常量引用的对象（方法区中有个结构 叫做 常量池 ，存储的一部分是常量），本地方法（线程独占区中有个结构叫做 本地方法栈）。

jvm里面有一个存储虚拟s1和s2

年轻代里面有一个复制算法，这个就要说到

第二步：垃圾回收器算法（标记-清除、复制算法、标记-整理、分代算法）

       1，标记-清除:找到垃圾类之后，标记一下。然后直接 清除即可。（算法很快）

           缺点：产生空间碎片，不利于大对象的安排进去。

       2,复制算法：将内存分为四块：新生代（Eden），生存代（Survivor * 2），老年代。有五种内存分配策略，讲完之后再说。类的升级流程是Eden->Survivor->老年代；

         算法流程：1），先找到垃圾类，将可以使用的类移动到Survivor2，将Eden + 另一块Survivor1中的内存全部清除。

                           2），将新生成的类实例优先分配到Eden，分配不下时，放到Survivor2。进行GC时，将Survivor2中对象的满足一定条件（例如对象年龄达到某一个标准）的对象分配到老年代中。将本次GC存活下来的分配到Survivor1中，在清除Eden + Survivor2 。依次循环即可。

       缺点：很容易发现吧，Survivor中每次都会浪费一个Survivor的内存没有使用，所以为了减少浪费，一般将Eden的内存扩大，Survivor的内存设置小一点。例如：HotSpot（HotSpot是8中的jvm默认虚拟机） 中设置的是 8 ： 1 ： 1；

    3，标记-整理：看名字是不是感觉很熟悉，没错。跟标记-清除很像，也是直接标记。改算法使用到了前面两个算法的精华，改善了缺点。

        算法流程：1），直接标记

                          2），集中，无缝隙的移动到一端，此时会发现，剩下的垃圾类，都会在其他地方。移动完成之后就会发现有一个边界，就是可用类跟其他空间的一个边界，下一步直接把边界以外的空间直接清除掉就可以了。

       缺点：看起来很完美，但是越完美的，往往在时间上过不去。

    4，分代算法：根据在哪里清除，选用算法不一样。

        算法流程：1），新生代采用复制算法

                          2），老年代采用标记-清除算法（老年代GC很少访问，类也很少去直接分配到里面，内存碎片的可怕性就显得不那么重要了）

什么样的数据会往老年代里面迁移呢；

每次进行垃圾回收的时候，比如说当前这个对象存活下来了，计数器就会给他+1，默认的话，是当计数器达到16的时候就会放到老年代里面；

GC的作用域：

JVM内存分配原则：

        1，对象优先分配到Eden区域；

        2，大对象直接分配到老年区：大对象的就是，对象里面有很大数组或者很大的字符串；

        3，长时间存活的对象存入老年区：就是上面复制算法里面说的那个对象升级流程；

         4，动态对象年龄判定：jvm并不是永远地要求对象的年龄必须达到了MaxTenuringThreshold才可以进入老年代，如果Survivor空间中年龄相同的所有对象的总空间>=本servivor中的一半，那么年龄>=本年龄的对象可以直接进入老年区；

        5，空间分配原则：简单来说，就是在发生Minor GC（在新生代进行GC）情况下，为了防止发生在Minor GC后，Eden有大量存活的对象，导致survivor不能全部存入，这时需要老年代去担保，把这些对象放入老年代，但是要确保老年要存的下。

               1），再发生Minor GC之前，检查老年区的可用的连续空间是否是大于新生代（Eden）的所有对象的总空间，如果是，直接全部晋升老年代，保证Minor GC的安全；

               2），如果不行，就检查HandlePromotionFailure（可以手工设定）参数时候允许担保失败，允许的话，直接分配。不能的话，发生一次full GC（或者是Major GC   在老年代进行GC）。

              3），不允许担保失败，发生一次 full GC。

            为什么不直接进行full GC ，因为速度慢呀。而且经常GC 也 效果不大，因为老年代都是一些长期存活的对象。

如果老年代内存也不够用了怎么办呢；

            他会进行fullGC

fullGC的时候会有什么现象吗；有没有遇到到fullGC的时候影响业务的场景；

如果频繁的fullGC会出现cpu内存飙升的问题

     收集器有：Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS、G1（G1是目前最好的收集器）

上图是HotSpot的垃圾收集器的使用范围，HotSpot是现在主流的 jvm。

CMS收集器

      CMS收集器是一种以获取最短回收停顿时间为目标的收集器。

     工作原理：基于标记-清除算法实现的，流程分为4步：

                       1），初始标记（仅仅标记一下GC Root，）

                       2），并发标记（是一个单独的线程，一起跟用户的线程一起 运行）

                       3），重新标记（去标记一下在运行期间发生变化的对象）

                       4），并发清除（是一个单独的线程，一起跟用户的线程一起 运行）

        其中，初始标记跟重新标记任然需要Stop The World。

图中的安全点，跟发动GC有关，任何一个GC收集器动作都会设计安全点。另附博客说明。

G1收集器：

      目前最强收集器，强到什么地步。不需要其他收集器配合，自己就可以管理新生代跟老年代。G1是面向服务端应用的垃圾收集器，HotSpot开发团队称在未来可以替换掉JDK1.5中发布的CMS收集器。

      工作流程：算法：整体采用了标记-整理算法，局部使用了复制算法。工作流程也是分为4步：

                        1），初始标记

                        2），并发标记

                        3），最终标记

                       4），筛选回收

跟CMS的工作流程差不多。因为G1还正在开发优化，在大数据上应用停顿时间以及吞吐量还有缺陷。还没有大方面的普及

五、数据库：

接触过哪些数据库；oracle和mysql分页的区别；oracle分页的原理；什么情况要加索引；那些字段上适合加索引；mycat会用吗；平时会自己弄分库分表吗；什么时候需要分库什么时候需要分表；你们现在的数据量大吗；是怎么进行拆分存储的；数据库是分库的对吧；他的分库的规则是什么样的；读锁和写锁的实现方式，加了读锁，其他资源能不能读，加了写锁其他资源能不能读；

接触过哪些数据库；

oracle mysql

oracle和mysql分页的区别；oracle分页的原理；

Mysql使用limit分页

select * from stu limit m, n; //m = (startPage-1)*pageSize,n = pageSize

Oracle使用rownum分页

select * from (
select rownum rn,a.* from table_name a where rownum <= x
//结束行，x = startPage*pageSize
)
where rn >= y; //起始行，y = (startPage-1)*pageSize+1

（1）>= y，<= x表示从第y行（起始行）~x行（结束行） 。

（2）rownum只能比较小于，不能比较大于，因为rownum是先查询后排序的，例如你的条件为rownum>1，当查询到第一条数据，rownum为1，则不符合条件。第2、3...类似，一直不符合条件，所以一直没有返回结果。所以查询的时候需要设置别名，然后查询完成之后再通过调用别名进行大于的判断。

什么情况要加索引,哪些字段上适合加索引；

表的主键、外键必须有索引；

经常出现在Where子句中的字段，特别是大表的字段，应该建立索引；

经常与其他表进行连接的表，在连接字段上应该建立索引；

索引应该建在小字段上，对于大的文本字段甚至超长字段，不要建索引；

使用索引的优缺点？

索引就像书的目录一样可以非常快速的定位到书的页面

优点：提高查询效率，没有索引的话查询数据库表会进行全表扫描

缺点：插入慢，占用硬盘空间

mycat会用吗；平时会自己弄分库分表吗；什么时候需要分库什么时候需要分表；

你们现在的数据量大吗；是怎么进行拆分存储的；数据库是分库的对吧；他的分库的规则是什么样的；

读锁和写锁的实现方式，加了读锁，其他资源能不能读，加了写锁其他资源能不能读；

数据库的并发操作会带来许多问题，比如丢失更新、不可重复读、读脏数据（幽灵数据）等等，为避免该类问题的产生，我们采用了封锁机制，一般DBMS进行并发控制的方法是封锁机制和事务机制。

最基本的封锁类型有两种：排它锁（Exclusive Locks，X锁）和共享锁（Share Locks，S锁）：

• 排它锁也称独占锁、写锁或X锁，若sessionA获得某数据表的排他锁权限，那么sessionA只能对该表进行读取或修改，其他session既不能读取也不能修改该表，更不能对该表加任何类型的锁，直到sessionA释放排它锁权限。加锁方式：lock tables tablename write；
• 共享锁也称读锁或S锁，若sessionA获得某数据表的共享锁权限，那么任何session（包括sessionA）只能对该表进行读取，不能修改该表，其他session可以对该数据表继续加S锁但不能加X锁，直到sessionA释放共享锁权限。加锁方式：set tables tablename read；

六、redis：

redis是什么语言开发的；redis底层的实现原理有去研究过吗；为什么redis的性能能达到这么快呢；redis里面有个string 你知道他的底层是怎么实现的；redis的keys为什么影响性能；你知道别的复杂度也是ologn的；一般用redis都做什么；什么是redis的缓存穿透；怎么解决这些问题；不通过ip过滤，最简单的方式怎么解决；什么是缓存雪崩；redis持久化问题；会有数据损失吗，开启aof的持久化吗；redis有做集群吗；怎么做集群的；分布式锁的实现方式；有哪些常见的数据分布式算法，比如说现在部署了3个redis，里面的内存是不一样的，怎么保证有一个内存回落到固定的一个redis实例上面的分布式算法；一致性hash算法相较于普通hash算法有什么优势；

redis是什么语言开发的；

Redis采用的是基于内存的采用的是单进程单线程模型的 KV 数据库，由C语言编写。

redis底层的实现原理有去研究过吗；为什么redis的性能能达到这么快呢；

官方提供的数据是可以达到100000+的QPS（每秒内查询次数）。

1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)；

2、数据结构简单，对数据操作也简单，Redis中的数据结构是专门进行设计的；

3、采用单线程，避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗；

4、使用多路I/O复用模型，非阻塞IO；

5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求；

多路 I/O 复用模型：

多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。

这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主要由以上几点造就了 Redis 具有很高的吞吐量。

原因是因为他底层的话是用的是这种io多路复用的这种机制像我们linux底下的这种epoll  就是根据事件来触发的 当你有这种事件的时候 就会通知我的  那我就会进行一个事件的触发 而且还防止了我们多线程之间的一个上下文切换或者锁的一些竞争的一些情况 从而他的性能会比较高一点  但是我们对其禁止使用一些严重影响他性能的一些命令 例如说是keys啊 这种 我们会给他重命名掉  不让他使用

redis里面有个string，一个字符串类型的值能存储最大容量是多少；你知道他的底层是怎么实现的；

最大容量是512M。

对于字符串类型，其做出了改进，是一种基于动态字符串sds实现，redis作为数据库，查询必然多，修改也会有一定多，sds解决了C语言字符串动态扩展的不方便，以及查询长度操作从O(n)变为了O(1)。 

struct sdshdr {// 记录 buf 数组中已使用字节的数量// 等于 SDS 所保存字符串的长度int len;// 记录 buf 数组中未使用字节的数量int free;// 字节数组，用于保存字符串char buf[];};

SDS 遵循 C 字符串以空字符结尾的惯例， 保存空字符的 1 字节空间不计算在 SDS 的 len 属性里面， 并且为空字符分配额外的 1 字节空间， 以及添加空字符到字符串末尾等操作都是由 SDS 函数自动完成的， 所以这个空字符对于 SDS 的使用者来说是完全透明的。

遵循空字符结尾这一惯例的好处是， SDS 可以直接重用一部分 C 字符串函数库里面的函数。

其free属性是代表buf数组没有被利用的空间数，便于sds的空间分配策略。

这样的设计也打破了C语言字符串会自动认为’\0’为分隔符号，但是sds不会，所以可以保存的字符串中间存在空字符 

通过未使用空间， SDS 实现了空间预分配和惰性空间释放两种优化策略

redis的keys为什么影响性能,redis时间复杂度是O(n)的命令；

keys时间复杂度是O(n)，flushdb、flushall这类命令我们可以配置redis.conf禁用这些命令

使用scan替代keys命令

语法：
scan cursor [MATCH pattern] [COUNT count]
案例：
scan 0 match report:* count 10
1) "3932160"
2)  1) "report:12360412"2) "report:12749274"
scan 第一个参数是游标，表示从游标开始
返回的第一行是游标，第二行是匹配到的数据，
如果第一行返回0，表示没有更多数据，否则下次使用scan时，就要用第一行返回的值作为scan的游标

一般用redis都做什么；

• 性能：

我们在碰到需要执行耗时特别久，且结果不频繁变动的SQL，就特别适合将运行结果放入缓存，这样，后面的请求就去缓存中读取，请求使得能够迅速响应。

• 并发：

在大并发的情况下，所有的请求直接访问数据库，数据库会出现连接异常。这个时候，就需要使用的的Redis的做一个缓冲操作，让请求先访问到的Redis的的，而不是直接访问数据库。

• 分布式锁等其他功能

Redis的的的还具备可以做分布式锁等其他功能，但是如果只是为了分布式锁这些其他功能，完全还有其他中间件代替，

什么是redis的缓存穿透；什么是缓存雪崩；怎么解决这些问题；缓存穿透不通过ip过滤，最简单的方式怎么解决；

• 缓存处理流程

      前台请求，后台先从缓存中取数据，取到直接返回结果，取不到时从数据库中取，数据库取到更新缓存，并返回结果，数据库也没取到，那直接返回空结果。

• 缓存穿透

       描述：

       缓存穿透是指缓存和数据库中都没有的数据，而用户不断发起请求，如发起为id为“-1”的数据或id为特别大不存在的数据。这时的用户很可能是攻击者，攻击会导致数据库压力过大。

      解决方案：

接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击

• 缓存击穿

      描述：

      缓存击穿是指缓存中没有但数据库中有的数据（一般是缓存时间到期），这时由于并发用户特别多，同时读缓存没读到数据，又同时去数据库去取数据，引起数据库压力瞬间增大，造成过大压力

      解决方案：

设置热点数据永远不过期。
加互斥锁，互斥锁参考代码如下：

          说明：

          1）缓存中有数据，直接走上述代码13行后就返回结果了

         2）缓存中没有数据，第1个进入的线程，获取锁并从数据库去取数据，没释放锁之前，其他并行进入的线程会等待100ms，再重新去缓存取数据。这样就防止都去数据库重复取数据，重复往缓存中更新数据情况出现。

          3）当然这是简化处理，理论上如果能根据key值加锁就更好了，就是线程A从数据库取key1的数据并不妨碍线程B取key2的数据，上面代码明显做不到这点。

• 缓存雪崩

      描述：

      缓存雪崩是指缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大甚至down机。和缓存击穿不同的是，        缓存击穿指并发查同一条数据，缓存雪崩是不同数据都过期了，很多数据都查不到从而查数据库。

     解决方案：

缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
如果缓存数据库是分布式部署，将热点数据均匀分布在不同搞得缓存数据库中。
设置热点数据永远不过期。

redis 和 memcached 的区别：

对于 redis 和 memcached 我总结了下面四点。现在公司一般都是用 redis 来实现缓存，而且 redis 自身也越来越强大了！

redis支持更丰富的数据类型（支持更复杂的应用场景）：Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，zset，hash等数据结构的存储。memcache支持简单的数据类型，String。
Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用,而Memecache把数据全部存在内存之中。
集群模式：memcached没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是 redis 目前是原生支持 cluster 模式的.
Memcached是多线程，非阻塞IO复用的网络模型；Redis使用单线程的多路 IO 复用模型。

Redis 哈希槽的概念

Redis 集群没有使用一致性 hash，而是引入了哈希槽的概念，Redis 集群有 16384个哈希槽，每个 key通过 CRC16校验后对16384 取模来决定放置哪个槽，集群的每个节点负责一部分 hash槽。

redis 设置过期时间；

定期删除+惰性删除。

定期删除：redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。注意这里是随机抽取的。为什么要随机呢？你想一想假如 redis 存了几十万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很大的负载！
惰性删除 ：定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个 key，才会被redis给删除掉。这就是所谓的惰性删除，也是够懒的哈！

如果大量过期key堆积在内存里，导致redis内存块耗尽了。怎么解决这个问题呢？ redis 内存淘汰机制。

redis 提供 6种数据淘汰策略：

redis有做集群吗；怎么做集群的；你在项目中还遇到什么问题吗；

参考：https://www.cnblogs.com/L-Test/p/11626124.html

 集群的三种模式：

一、主从同步/复制

redis有俩种复制模式：Rdb和aof

redis持久化问题；会有数据损失吗，开启aof的持久化吗；

redis提供2种持久化方案。rdb和aof

redis有自己默认的持久化方案 （Rdb 方案）

Rdb(默认)：在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。
AOF：append only file。以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。

优缺点：

相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。

由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。不过生产环境其实更多都是二者结合使用的。

常用配置

RDB持久化配置

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1              #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。
save 300 10            #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。
save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always     #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec  #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no          #从不同步。高效但是数据不会被持久化。

（1）首先从节点根据当前状态，决定如何调用psync命令：

• 如果从节点之前未执行过slaveof或最近执行了slaveof no one，则从节点发送命令为psync ? -1，向主节点请求全量复制；
• 如果从节点之前执行了slaveof，则发送命令为psync <runid> <offset>，其中runid为上次复制的主节点的runid，offset为上次复制截止时从节点保存的复制偏移量。

（2）主节点根据收到的psync命令，及当前服务器状态，决定执行全量复制还是部分复制：

• 如果主节点版本低于Redis2.8，则返回-ERR回复，此时从节点重新发送sync命令执行全量复制；
• 如果主节点版本够新，且runid与从节点发送的runid相同，且从节点发送的offset之后的数据在复制积压缓冲区中都存在，则回复+CONTINUE，表示将进行部分复制，从节点等待主节点发送其缺少的数据即可；
• 如果主节点版本够新，但是runid与从节点发送的runid不同，或从节点发送的offset之后的数据已不在复制积压缓冲区中(在队列中被挤出了)，则回复+FULLRESYNC <runid> <offset>，表示要进行全量复制，其中runid表示主节点当前的runid，offset表示主节点当前的offset，从节点保存这两个值，以备使用。

二、哨兵模式

　　Redis Sentinel是Redis高可用的实现方案。Sentinel是一个管理多个Redis实例的工具，它可以实现对Redis的监控、通知、自动故障转移。

Redis Sentinel的工作流程

由一个或多个Sentinel实例组成的Sentinel系统可以监视任意多个主服务器，以及所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求 。如下图：

Sentinel负责监控集群中的所有主、从Redis，当发现主故障时，Sentinel会在所有的从中选一个成为新的主。并且会把其余的从变为新主的从。同时那台有问题的旧主也会变为新主的从，也就是说当旧的主即使恢复时，并不会恢复原来的主身份，而是作为新主的一个从。

在Redis高可用架构中，Sentinel往往不是只有一个，而是有3个或者以上。目的是为了让其更加可靠，毕竟主和从切换角色这个过程还是蛮复杂的。

• 主观失效

  SDOWN（subjectively down）,直接翻译的为”主观”失效,即当前sentinel实例认为某个redis服务为”不可用”状态.

• 客观失效

  ODOWN（objectively down）,直接翻译为”客观”失效,即多个sentinel实例都认为master处于”SDOWN”状态,那么此时master将处于ODOWN,ODOWN可以简单理解为master已经被集群确定为”不可用”,将会开启failover

三、Cluster 集群

使用虚拟节点，比如说有3主、3从6台服务器。将16384个槽均匀的分配到三台主服务器（master）上，从服务器（slave）复制主服务器上的所有数据，存储key时，通过CRC16（key）算法得到32位的哈希值在和16384取模，计算出槽的编号。因为redis是非幂等性（无状态的，每次请求服务和请求别的是一样的）的服务，必须要搭从节点。

部署集群：借助 redis-tri.rb 工具可以快速的部署集群，如果本机没有该命令行需要自行安装，只需要执行/redis-trib.rb create --replicas 1 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 127.0.0.1:6385 就可以成功创建集群。

后面如果扩容或者删除从节点，对我们的数据的影响都不会很大，因为主要是扩容节点的，因为redis是无中心化的，我们只需要去连接一台服务器的redis，如果key不在目前这台服务器上，他就可以帮你重定向到另一台服务器，对数据进行操作，我们在操作数据的时候，必须使用“-c”来表示我们操作的是集群，而不是在单服务器上进行操作的。

如何解决 Redis 的并发竞争 Key 问题

所谓 Redis 的并发竞争 Key 的问题也就是多个系统同时对一个 key 进行操作，但是最后执行的顺序和我们期望的顺序不同，这样也就导致了结果的不同！

推荐一种方案：分布式锁（zookeeper 和 redis 都可以实现分布式锁）。（如果不存在 Redis 的并发竞争 Key 问题，不要使用分布式锁，这样会影响性能）

基于zookeeper临时有序节点可以实现的分布式锁。大致思想为：每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。 当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。完成业务流程后，删除对应的子节点释放锁。

在实践中，当然是从以可靠性为主。所以首推Zookeeper。

参考：

https://www.jianshu.com/p/8bddd381de06

cps是多少；一秒钟处理多少；

分布式锁的实现方式；有哪些常见的数据分布式算法，比如说现在部署了3个redis，里面的内存是不一样的，怎么保证有一个内存回落到固定的一个redis实例上面的分布式算法；一致性hash算法相较于普通hash算法有什么优势；

你对sentinel hystrix有用过吗；你们微服务有用sentinel 吗

因为他需要监控redis里面 因为redis属于非幂等性的集群 那我搭建完集群之后我还需要搭建主从复制 如果说我们不用sentinel 的话肯定会对我们数据造成一定的影响的 

sentinel 是你们自己搭的吗直接从ali看了 就搭了吗？hystrix你们也用过吗

说一下你们的熔断是怎么做的

当我们另一个服务不能用的时候他会调用failback给他返回一个页面

你认为什么时候是不可用的

当高并发或者是服务降级的时候 你这个系统可能不是很重要这个时候就会出发这种failback

sentinel hystrix的区别

你们用redis主要是用的缓存这一块吗说一下你怎么用redis实现分布式锁的

它提供了这种命令像nx ex 也就是说是给他指定的一个变量然后当他为1的时候肯定是一个加锁的状态那么如果说是我操作完之后的话 我是要对他进行一个释放的 然后别的会通过这个命令来判断如果当前存在而且为1的话他肯定是拿不到锁的

七、MQ:

MQ用过什么MQ；消息会有消费失败的情况吗，消费失败系统怎么处理；如果消费端异常，后续的操作流程是什么；死信队列如果消息失败可以放；mq的更新频路是怎么设置的；

消息会有消费失败的情况吗;消费失败系统怎么处理；

kafka的底层是怎么实现的；怎么可以达到这么高的吞吐量

他的话 底层也是使用的多路复用的这种形式 就是我作为一个数据的提供者我去发消息 那么他的话把topic分成一个个postion然后提高并发量所以他的一个性能的话 其实也跟这个有很大的关系 其实postion底层的话 数据的存储也是根据.log文件 跟日志也比较容易混淆 里面的话使用sengment对底层存储分段就是它里面有一个偏移量offset 然后发送他kafka服务器brock上 我们要进行一个存储 我们会根据我们的业务场景进行一个设计来保证我们数据丢失的一个情况 他的话我们平常的话也会设置成为1的一个情况 1的话就是我当前的一个lander接收到就行了 -1的话可能是这个lrp里面所有的从节点都接受到这个数据之后我们才给反馈  客户这边的话发数据也会分这种buffer  我们会给buffer定义一个长度 还有就是分批的一个处理 我给他每次手机达到一个batch  也会去设计一个批处理的量 达到这个数据量之后每一个时间段我给他发送  想这些都可以提高性能

你们用kafka有遇到什么问题吗；

如果保证一个消息消费他是有序的怎么做

客户端获取到的每一个postion的数据  其实都是有序的 但是我们客户端这边可能说是并发的这种情况那我们会给他加一个内存优化之类的

kafka和activemq和ribbitmq的区别

activemq因为他是用java开发的，不支持跨语言的这种形式。ribbitmq的话他主要是用在事务级别的，对大数据的处理性能比较弱一点。

如果消费端异常，后续的操作流程是什么；

死信队列如果消息失败可以放；mq的更新频路是怎么设置的；

八、jdk1.8有什么新特性；

【1】Lambda 表达式：将函数式编程引入了Java。Lambda 允许把函数作为一个方法的参数，或者把代码看成数据。

String[] atp = {"Nadal", "Djokovic",  "Wawrinka"};  
List<String> players =  Arrays.asList(atp);  // 以前的循环方式  
for (String player : players) {  System.out.print(player + "; ");  
}  
// 使用 lambda 表达式以及函数操作(functional operation)  
players.forEach((player) -> System.out.print(player + "; "));  

【2】接口的默认方法与静态方法：我们可以在接口中定义默认方法，使用 default关键字，并提供默认的实现。所有实现这个接口的类都会接受默认方法的实现，除非子类提供的自己的实现。

public interface DefaultFunctionInterface {default String defaultFunction() {return "default function";}
}//我们还可以在接口中定义静态方法，使用static关键字，也可以提供实现。
public interface StaticFunctionInterface {static String staticFunction() {return "static function";}
}

【3】方法引用：通常与 Lambda表达式联合使用，可以直接引用已有 Java类或对象的方法。
【4】重复注解：在 Java 5中使用注解有一个限制，即相同的注解在同一位置只能声明一次。Java 8 引入重复注解，这样相同的注解在同一地方也可以声明多次。重复注解机制本身需要用@Repeatable注解。Java 8在编译器层做了优化，相同注解会以集合的方式保存，因此底层的原理并没有变化。
【5】扩展注解的支持：Java 8 扩展了注解的上下文，几乎可以为任何东西添加注解，包括局部变量、泛型类、父类与接口的实现，连方法的异常也能添加注解。
【6】Optional：Java 8 引入 Optional 类来防止空指针异常，Optional 类最先是由 Google 的 Guava项目引入的。Optional类实际上是个容器：它可以保存类型T的值，或者保存null。使用Optional类我们就不用显式进行空指针检查了。

Optional<String> str = Optional.of("test");
//1、判断str是否为null，如果不为null，则为true，否则为false
if (str.isPresent()) {//get用于获取变量的值，当变量不存在的时候会抛出NoSuchElementException，如果不能确定变量一定存在值，则不推荐使用str.get();
}

【7】Stream：Stream API 是把真正的函数式编程风格引入到 Java中。其实简单来说可以把 Stream理解为 MapReduce，当然Google 的 MapReduce的灵感也是来自函数式编程。她其实是一连串支持连续、并行聚集操作的元素。从语法上看，也很像 Linux的管道、或者链式编程，代码写起来简洁明了，非常酷帅！
【8】Date/Time API (JSR 310)：Java 8 新的 Date-Time API (JSR 310)受Joda-Time的影响，提供了新的 java.time包，可以用来替代 java.util.Date和 java.util.Calendar。一般会用到 Clock、LocaleDate、LocalTime、LocaleDateTime、ZonedDateTime、Duration这些类，对于时间日期的改进还是非常不错的。
【9】JavaScript 引擎 Nashorn：Nashorn允许在 JVM上开发运行 JavaScript应用，允许 Java与 JavaScript相互调用。
【10】Base64：在 Java 8中，Base64 编码成为了Java类库的标准。Base64 类同时还提供了对URL、MIME友好的编码器与解码器。