面试总结day2:线程池阻塞队列、RabbitMQ重复消费问题、synchronize和分布式锁

1.线程池阻塞队列分类:

**1.ArrayBlockingQueue 数组型阻塞队列
2.LinkedBlockingQueue 链表型阻塞队列
3.DelayQueue 延时队列
4.SynchronousQueue 同步队列
5.PriorityBlockingQueue 优先阻塞队列**	

ArrayBlockingQueue 数组型阻塞队列
特点：
初始化一定容量的数组
使用一个重入锁，默认使用非公平锁，入队和出队共用一个锁，互斥
是有界设计，如果容量满无法继续添加元素直至有元素被移除
使用时开辟一段连续的内存，如果初始化容量过大容易造成资源浪费，过小易添加失败
LinkedBlockingQueue 链表型阻塞队列
特点：
内部使用节点关联，会产生多一点内存占用
使用两个重入锁分别控制元素的入队和出队，用Condition进行线程间的唤醒和等待
有边界的，在默认构造方法中容量是Integer.MAX_VALUE,非连续性内存空间
DelayQueue 延时队列
特点：
无边界设计
添加（put）不阻塞，移除阻塞
元素都有一个过期时间
取元素只有过期的才会被取出
SynchronousQueue 同步队列
特点：
内部容量是0
每次删除操作都要等待插入操作
每次插入操作都要等待删除操作
一个元素，一旦有了插入线程和移除线程，那么很快由插入线程移交给移除线程，这个容器相当于通道，本身不存储元素在多任务队列，是最快的处理任务方式。
PriorityBlockingQueue 优先阻塞队列
特点：
无边界设计，但容量实际是依靠系统资源影响
添加元素，如果超过1，则进入优先级排序

2.RabbitMQ重复消费问题

解决:是个消息设置唯一id在redis中进行setnx,如果存在说明已经消费过了,如果不存在说明还没有消费.

3.分布式锁和synchronize的区别

1.synchronized是基于JVM，在分布式部署多台实例的情况下，不能实现功能
为什么分布式场景使用synchronized依然会出现线程安全问题？
**因为synchronized是JVM进程级别的锁，由于分布式部署原因，同样的synchronized代码块内容在不同的服务器（tomcat1和tomcat2）运行时，抢占的不是同一把锁。**所以当多个请求通过Nginx分发到不同的tomcat服务器，此时synchronized没办法保证线程安全问题，因为图中这两台tomcat上的synchronized使用的不是同一个锁，就没办法保证线程安全，这时就需要使用分布式锁！