java面经

1.HashMap在jdk1.8之后引入了红黑树的概念，表示若桶中链表元素超过8时，会自动转化成红黑树；若桶中元素小于等于6时，树结构还原成链表形式。
红黑树的平均查找长度是log(n)，长度为8，查找长度为log(8)=3，链表的平均查找长度为n/2，当长度为8时，平均查找长度为8/2=4，这才有转换成树的必要；链表长度如果是小于等于6，6/2=3，虽然速度也很快的，但是转化为树结构和生成树的时间并不会太短。
还有选择6和8的原因是：
中间有个差值7可以防止链表和树之间频繁的转换。假设一下，如果设计成链表个数超过8则链表转换成树结构，链表个数小于8则树结构转换成链表，如果一个HashMap不停的插入、删除元素，链表个数在8左右徘徊，就会频繁的发生树转链表、链表转树，效率会很低。
链表的由来：Hash碰撞：不同的元素通过hash算法可能会得到相同的hash值，如果都放同一个桶里，后面放进去的就会覆盖前面放的，所以为了解决hash碰撞时元素被覆盖的问题，就有了在桶里放链表。

②红黑树的由来：假设现在HashMap集合中大多数的元素都放到了同一个桶里（由hash值计算而得的桶的位置相同），那么这些元素就在这个桶后面连成了链表。现在需要查询某个元素，那么此时的查询效率就很慢了，它是在做链表查询（ O(N) 的查询效率）。为了解决这个问题，就引入了红黑树（ log(n) 的查询效率）：当链表到达一定长度时就在链表的后面创建红黑树。

③其实，“尽量避免hash 冲突，让元素较为均匀的放置到每个桶”才是查询效率最高的（ O(1) 的查询效率）
2.红黑树的定义
1.自平衡的二叉查找树，根节点是黑色。
3.每个叶子节点都是黑色的空节点（NIL节点）。
4 每个红色节点的两个子节点都是黑色。(从每个叶子到根的所有路径上不能有两个连续的红色节点)
5.从任一节点到其每个叶子的所有路径都包含相同数目的黑色节点。
当链表已经有8个节点了，此时再新链上第9个节点，在成功添加了这个新节点之后，立马做链表转红黑树”。

3.JDK中消费者生产者应用场景

在新增的Concurrent包中，BlockingQueue很好的解决了多线程中，首先它是一个队列，多线程环境中，通过队列可以很容易实现数据共享，比如经典的“生产者”和“消费者”模型中，通过队列可以很便利地实现两者之间的数据共享，在多线程领域：所谓阻塞，在某些情况下会挂起线程（即阻塞），一旦条件满足，被挂起的线程又会自动被唤醒。
　**总结：**通过一个容器来解决生产者与消费者的强耦合关系，生产者与消费者之间不直接进行通讯，而是利用阻塞队列来进行通讯，生产者生成数据后直接丢给阻塞队列，消费者需要数据则从阻塞队列获取，实际应用中，生产者与消费者模式则主要解决生产者与消费者生产与消费的速率不一致的问题，达到平衡生产者与消费者的处理能力，而阻塞队列则相当于缓冲区。

1. ArrayBlockingQueue
　在生产者放入数据和消费者获取数据，都是共用同一个锁对象，由此也意味着两者无法真正并行运行，这点尤其不同于LinkedBlockingQueue；
　ArrayBlockingQueue和LinkedBlockingQueue间还有一个明显的不同之处在于，前者在插入或删除元素时不会产生或销毁任何额外的对象实例，而后者则会生成一个额外的Node对象。这在长时间内需要高效并发地处理大批量数据的系统中，其对于GC的影响还是存在一定的区别。而在创建ArrayBlockingQueue时，我们还可以控制对象的内部锁是否采用公平锁，默认采用非公平锁。（利用reentrantlock）
　2.LinkedBlockingQueue
　当生产者往队列中放入一个数据时，队列会从生产者手中获取数据，并缓存在队列内部，而生产者立即返回；只有当队列缓冲区达到最大值缓存容量时（LinkedBlockingQueue可以通过构造函数指定该值），才会阻塞生产者队列，直到消费者从队列中消费掉一份数据，生产者线程会被唤醒，反之对于消费者这端的处理也基于同样的原理。而LinkedBlockingQueue之所以能够高效的处理并发数据，还因为其对于生产者端和消费者端分别采用了独立的锁来控制数据同步，这也意味着在高并发的情况下生产者和消费者可以并行地操作队列中的数据，以此来提高整个队列的并发性能。
　3.PriorityBlockingQueue
　无界，平衡二叉堆的数组结构，保存的对象必须实现Comparable接口，按此比较规则来排序。迭代器的输出是二叉堆数组顺序，无法保证排序。

4.Synchronized和ReentrantLock

1.ReentrantLock
reentrantLock提供了更多，更加全面的功能，具备更强的扩展性。例如：时间锁等候，可中断锁等候，锁投票。提供公平锁，非公平锁（允许插队）
2）ReentrantLock还提供了条件Condition，对线程的等待、唤醒操作更加详细和灵活，所以在多个条件变量和高度竞争锁的地方，Condition是在java 1.5中才出现的，它用来替代传统的Object的wait()、notify()实现线程间的协作，相比使用Object的wait()、notify()，使用Condition的await()、signal()这种方式实现线程间协作更加安全和高效，Condition可以实现多路通知功能，也就是在一个Lock对象里可以创建多个Condition（即对象监视器）实例
　ReentrantLock的锁释放一定要在finally中处理，否则可能会产生严重的后果。当 JVM 用 synchronized 管理锁定请求和释放时，JVM 在生成线程转储时能够包括锁定信息。这些对调试非常有价值，因为它们能标识死锁或者其他异常行为的来源。

servlet怎么响应浏览器请求

服务器接收到浏览器的请求后， 会创建一个 Request 对象， 对象中
存储了此次请求相关的请求数据。 服务器在调用 Servlet 时会将创建的
Request 对象作为实参传递给 Servlet 的方法， 比如： service 方法，而 response 则是用来进行响应的一个对象。
使用：
设置响应头
设置响应编码格式设置响应实体
请求乱码问题解决:

Arraylist扩充机制

ArrayList的构造函数总共有三个：
（1）ArrayList()构造一个初始容量为 10 的空列表。
（2）ArrayList(Collection<? extends E> c)构造一个包含指定 collection 的元素的列表，这些元素是按照该 collection 的迭代器返回它们的顺序排列的。
（3）ArrayList(int initialCapacity)构造一个具有指定初始容量的空列表。
HashMap的初始大小为16，增长时，直接容量翻番，如源代码。
Vector的初始大小为10，如果没有指定每次增长的大小，则默认是翻倍增长。

Bean 的初始化过程

１、ResourceLoader从存储介质中加载Spring配置信息，并使用Resource表示这个配置文件的资源；
２、BeanDefinitionReader读取Resource所指向的配置文件资源，然后解析配置文件解析成一个BeanDefinition对象，并保存到BeanDefinitionRegistry中；
３、容器扫描BeanDefinitionRegistry中的BeanDefinition，使用Java的反射机制自动识别出Bean工厂后处理后器（实现BeanFactoryPostProcessor接口）的Bean，
4．Spring容器从BeanDefinitionRegistry中取出加工后的BeanDefinition，并调用InstantiationStrategy着手进行Bean实例化的工作；

5．在实例化Bean时，Spring容器使用BeanWrapper对Bean进行封装，BeanWrapper提供了很多以Java反射机制操作Bean的方法，它将结合该Bean的BeanDefinition以及容器中属性编辑器，完成Bean属性的设置工作；

6．利用容器中注册的Bean后处理器（实现BeanPostProcessor接口的Bean）对已经完成属性设置工作的Bean进行后续加工，直接装配出一个准备就绪的Bean。
一个类同时实现了 BeanNameAware, BeanFactoryAware, ApplicationContextAware, BeanPostProcessor, InitializingBean, DisposableBean接口时，Bean 的初始化过程为：.

调用 BeanNameAware 的 setBeanName 方法
调用 BeanFactoryAware 的 setBeanFactory 方法
调用 ApplicationContextAware 的 setApplicationContext
调用 InitializingBean 的 afterPropertiesSet 或者没有实现这个接口，但指定了@Bean(initMethod=“不加括号的方法名”)，会执行这个方法
调用 BeanPostProcessor 的 postProcessBeforeInitialization 方法
调用 BeanPostProcessor 的 postProcessAfterInitialization 方法
Bean 初始化完成，可以被使用
容器关闭前，调用 DisposableBean 的 destroy 方法
但是在整个系统中，BeanPostProcessor的实现类只需要有一个即可，Spring 检测到它的存在时，每个 Bean 被初始化时，都会调用它的方法。注意，是所有 Bean 都会调用它的方法。
如果一个类除BeanPostProcessor外，实现了其他的接口，有另外一个类单独实现了BeanPostProcessor接口，那么上面的初始化过程中，第 4 步和第 5 步调换位置。

下单的时候库存为零怎么处理

1.高并发，当前有三个用户a、b、c三个用户进入到了这个事务中，这个时候会产生一个共享锁，所以在select的时候，这三个用户查到的库存数量都是>=0的。update，假如这三个用户同时到达update这里，这个时候update更新语句会把并发串行化，也就是给同时到达这里的是三个用户排个序，一个一个执行，并生成排他锁，
所以可以调整一下顺序，先update，再select
2.一般不直接操作数据库，可以设置缓存，设置一个计数器来记录请求数，比如你想卖出10个商品，只允许100个请求进来。那当计数器达到100的时候，后面进来的就显示秒杀结束，这样可以减轻你的服务器的压力。然后根据这100个请求，使用消息队列来实现，先付款的先得后付款的提示商品以秒杀完。
3.不建议在数据库层面加锁，建议通过服务端的内存锁（锁主键）。当某个用户要修改某个id的数据时，把要修改的id存入memcache，若其他用户触发修改此id的数据时，读到memcache有这个id的值时，就阻止那个用户修改。
4.有多台服务器时，可以采用分流的形式实现，
假设有m张票, 有n台产品服务器接收请求,有x个请求路由服务器随机转发
直接给每台产品服务器分配 m/n张票
每台产品服务器内存做计数器,比如允许m/n*(1+0.1)个人进来。
当内存计数器已满：
后面进的人, 直接跳到到转到活动结束的静态页面，
通知路由服务器,不在路由到这台服务器(这个值得商讨)。
所有产品服务器进来的m/n(1+0.1)个人再全部转发到一台付款服务器上*,进入付款环节,看谁手快了,这时候人少,加锁什么的就简单的。

订单数大千万级,数据库怎么优化

1.mysql数据库本身高度灵活，造成性能不足，严重依赖开发人员能力
表字段避免null值出现，
null值很难查询优化且占用额外的索引空间，推荐默认数字0代替null。单表不要有太多字段，使用枚举或整数代替字符串类型，尽量使用TIMESTAMP而非DATETIME，即选择合适的数据类型
2.选择合适的索引列，
查询频繁的列，where条件中<，<=，=，>，>=，between，in，以及like 字符串+通配符（%）出现的列；长度小的列，索引字段越小越好，因为数据库的存储单位是页，一页中能存下的数据越多越好
3.sql的编写需要注意优化，
使用limit对查询结果的记录进行限定
避免select *，将需要查找的字段列出来
使用连接（join）来代替子查询
拆分大的delete或insert语句
4.分区
对用户来说，分区表是一个独立的逻辑表，但是底层由多个物理子表组成，实现分区的代码实际上是通过对一组底层表的对象封装，但对SQL层来说是一个完全封装底层的黑盒子。从而使查询定位到少量的分区上，否则就会扫描全部分区；
分区表的数据更容易维护，可以通过清楚整个分区批量删除大量数据，也可以增加新的分区来支持新插入的数据。
部分查询能够从查询条件确定只落在少数分区上，速度会很快
分区表的数据还可以分布在不同的物理设备上，从而搞笑利用多个硬件设备
分区的限制和缺点：
一个表最多只能有1024个分区
如果分区字段中有主键或者唯一索引的列，那么所有主键列和唯一索引列都必须包含进来
分区表无法使用外键约束
NULL值会使分区过滤无效
所有分区必须使用相同的存储引擎
5.引擎
目前广泛使用的是MyISAM和InnoDB两种引擎：MyISAM适合SELECT密集型的表，而InnoDB适合INSERT和UPDATE密集型的表（同时支持事务）
6.分表
表就是把一张大表，按照如上过程都优化了，还是查询卡死，那就把这个表分成多张表，把一次查询分成多次查询，然后把结果组合返回给用户。

分表分为垂直拆分和水平拆分，通常以某个字段做拆分项。比如以id字段拆分为100张表： 表名为 tableName_id%100

但：分表需要修改源程序代码，会给开发带来大量工作，极大的增加了开发成本，故：只适合在开发初期就考虑到了大量数据存在，做好了分表处理，不适合应用上线了再做修改，成本太高！！！而且选择这个方案，都不如选择我提供的第二第三个方案的成本低！故不建议采用。
7.分库
把一个数据库分成多个，建议做个读写分离就行了，真正的做分库也会带来大量的开发成本，得不偿失！不推荐使用。