面试题：

进程间的通讯方式？
管道
消息队列
信号量
共享内存

线程同步方式？（同步：按预定的先后次序进行运行）
1、互斥对象：只有拥有互斥对象的线程才有访问公共资源的权限。因为互斥对象只有一个，所以能保证公共资源不会同时被多个线程同时访问。当前拥有互斥对象的线程处理完任务后必须将线程交出，以便其他线程访问该资源。
2、事件对象：通过通知操作的方式来保持线程的同步，还可以方便实现对多个线程的优先级比较的操作。
3、临界区：通过对多线程的串行化来访问公共资源或一段代码，速度快，适合控制数据访问。在任意时刻只允许一个线程对共享资源进行访问，如果有多个线程试图访问公共资源，那么在有一个线程进入后，其他试图访问公共资源的线程将被挂起，并一直等到进入临界区的线程离开，临界区在被释放后，其他线程才可以抢占。它并不是核心对象，不是属于操作系统维护的，而是属于进程维护的。
4、信号量：信号量也是内核对象。它允许多个线程在同一时刻访问同一资源，但是需要限制在同一时刻访问此资源的最大线程数目。

java内存模式？

GC有几种方式？
1、标记清除方式：首先从根开始将可能被引用的对象用递归的方式进行标记，然后将没有标记到的对象作为垃圾进行回收。
2、复制收集方式：将从根开始被引用的对象复制到另外的空间中，然后，再将复制的对象所能够引用的对象用递归的方式不断复制下去。然后新空间的对象就是gc之后的对象，而老空间被gc。
3、引用计数方式：它的原理是：在每个对象中保存该对象的引用计数，当引用发生增减时对计数进行更新。当引用数为0时，引用失效。

java怎么实现多线程？
1、继承thread类
2、实现runnable接口，重写run方法
3、使用线程池
4、实现callable接口，重写call方法

Java创建线程的方法？
1、继承thread类。
2、实现runnable接口
3、通过callable和future实现

HashMap多线程操作可能出现的问题？
1、形成死循环，cpu使用率飙升
2、map.size()不准确
3、数据丢失

Java哪个内存区域不会发生OOM异常？
（OOM out of memory 内存溢出）
java中一般有三个内存区域
堆：一般存放的都是对象
栈：一般存放的都是对象引用
方法区：一般存放的都是对象的变量

为什么MYSQL的index使用B+树？
点这里

Volatile?
弱同步机制，即volatile变量，用来确保将变量的更新操作通知其他线程。当吧一个变量声明为volatile时，编译器与运行时都会注意到这个变量是共享的，因此不会将该变量与其他变量重排序。
在执行volatile操作时不会执行锁操作，因此也就不会使线程阻塞，所以是一种比synchronized更轻量级的同步机制。
当一个变量被定义为volatile时，会具备两种特性。
1、保证此变量对所有线程是可见的。
2、禁止重排序优化。

volatile 的读性能消耗与普通变量几乎相同，但是写操作稍慢

Mysql中的索引什么情况下无法使用？
1、查询条件中出现 or

select * from sc where id = '123' or name = 'wangcai'

2、like查询中以%开头

select * from sc where id like '%123'

3、字符串型数据没有加‘’ 引号

select * from sc where id = 123

4、如果mysql估计使用全表扫描要比使用索引快,则不使用索引

数据库索引的底层实现原理和优化？
顺序查找 > 二分查找 > 二叉排序树查找 >B树查找 > 红黑树查找

如何做一个高并发的系统？
点这里
（1）系统拆分，将一个系统拆分为多个子系统，用dubbo来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，不也可以抗高并发么。

（2）缓存，必须得用缓存。大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家redis轻轻松松单机几万的并发啊。没问题的。所以你可以考虑考虑你的项目里，那些承载主要请求的读场景，怎么用缓存来抗高并发。

（3）MQ，必须得用MQ。可能你还是会出现高并发写的场景，比如说一个业务操作里要频繁搞数据库几十次，增删改增删改，疯了。那高并发绝对搞挂你的系统，你要是用redis来承载写那肯定不行，人家是缓存，数据随时就被LRU了，数据格式还无比简单，没有事务支持。所以该用mysql还得用mysql啊。那你咋办？用MQ吧，大量的写请求灌入MQ里，排队慢慢玩儿，后边系统消费后慢慢写，控制在mysql承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用MQ来异步写，提升并发性。MQ单机抗几万并发也是ok的，这个之前还特意说过。

（4）分库分表，可能到了最后数据库层面还是免不了抗高并发的要求，好吧，那么就将一个数据库拆分为多个库，多个库来抗更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高sql跑的性能。

（5）读写分离，这个就是说大部分时候数据库可能也是读多写少，没必要所有请求都集中在一个库上吧，可以搞个主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库。

（6）Elasticsearch，可以考虑用es。es是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器来抗更高的并发。那么一些比较简单的查询、统计类的操作，可以考虑用es来承载，还有一些全文搜索类的操作，也可以考虑用es来承载。