1、synchronized锁升级
偏向锁
在 JDK1.8 中，其实默认是轻量级锁，但如果设定了 -XX:BiasedLockingStartupDelay = 0 ，那在对一个 Object 做 syncronized 的时候，会立即上一把偏向锁。当处于偏向锁状态时， markwork 会记录当前线程 ID 。
升级到轻量级锁
当下一个线程参与到偏向锁竞争时，会先判断 markword 中保存的线程 ID 是否与这个线程 ID 相等，如果不相等，会立即撤销偏向锁，升级为轻量级锁。每个线程在自己的线程栈中生成一个 LockRecord ( LR )，然后每个线程通过 CAS (自旋)的操作将锁对象头中的 markwork 设置为指向自己的 LR 的指针，哪个线程设置成功，就意味着获得锁。关于 synchronized 中此时执行的 CAS 操作是通过 native 的调用 HotSpot 中 bytecodeInterpreter.cpp 文件 C++ 代码实现的，有兴趣的可以继续深挖。
升级到重量级锁
如果锁竞争加剧(如线程自旋次数或者自旋的线程数超过某阈值， JDK1.6 之后，由 JVM 自己控制该规则)，就会升级为重量级锁。此时就会向操作系统申请资源，线程挂起，进入到操作系统内核态的等待队列中，等待操作系统调度，然后映射回用户态。在重量级锁中，由于需要做内核态到用户态的转换，而这个过程中需要消耗较多时间，也就是"重"的原因之一。
2、CAS的问题
ABA问题，可以用版本号来避免这个问题。
具体可以看这篇：
https://blog.csdn.net/summerZBH123/article/details/80642467
3、原子类原理
具体可以看这篇：
https://blog.csdn.net/lpq374606827/article/details/79354969
4、LongAdder原理
LongAdder类与AtomicLong类的区别在于高并发时前者将对单一变量的CAS操作分散为对数组cells中多个元素的CAS操作，取值时进行求和；而在并发较低时仅对base变量进行CAS操作，与AtomicLong类原理相同。
具体可以看这篇：
https://www.jianshu.com/p/ec045c38ef0c
5、伪共享
CPU缓存从内存读数据时，是按行读取的，即使只用到一个变量，也要将整行数据进行读取，这行数据量可能包含其他变量。当多个线程同时修改同一个缓存行里的不同变量时，由于同时只能有一个线程在操作，所以相比将每个变量放到不同缓存行里，性能会有所下降。（补充：缓存一致性协议）
伪共享出现的原因：因为CPU缓存和内存交换数据的单位是缓存行
如何避免伪共享：字节填充（创建变量时，使用字段对其进行填充，避免多个变量被分派到同一个缓存行里）
具体可以看这篇：
https://www.jianshu.com/p/a4358d39adac
6、JVM内存结构
本地方法栈、Java虚拟机栈、程序计数器、堆、元空间、直接内存
7、垃圾收集算法
标记清除（碎片化）
复制算法（浪费空间）
标记整理算法（效率比前两者差）
分代收集算法（老年代一般使用“标记-清除”、“标记-整理”算法，年轻代一般用复制算法）
8、弱引用跟软引用的区别
软引用一般用于维护一些可有可无的对象。在内存足够的时候，软引用对象不会被回收，只有在内存不足时，系统则会回收软引用对象，如果回收了软引用对象之后仍然没有足够的内存，才会抛出内存溢出异常。
弱引用对象相比较软引用，要更加无用一些，它拥有更短的生命周期。当JVM进行垃圾回收时，无论内存是否充足，都会回收被弱引用关联的对象。
9、分代收集算法
老年代一般使用“标记-清除”、“标记-整理”算法，年轻代一般用复制算法。
10、ThreadLocal原理
可以看这篇：
https://www.jianshu.com/p/98b68c97df9b
11、怎么停止线程
可以看这篇：
http://c.biancheng.net/view/1186.html
12、MySQL引擎
13、innodb索引为什么要用B+树，不用二叉树？
innodb索引是按页存储的，相同数据量二叉树的高度比B+树高，高度越高，磁盘IO次数越多，效率也就越低。所以用B+树是为了减少磁盘IO次数。
14、聚簇索引
可以看这篇：
https://www.cnblogs.com/jiawen010/p/11805241.html
15、Redis数据结构
字符串(String)、哈希(hash)、列表(list)、集合(set)、有序集合(short set)
16、IO模型
1.阻塞IO（blocking I/O）
A拿着一支鱼竿在河边钓鱼，并且一直在鱼竿前等，在等的时候不做其他的事情，十分专心。只有鱼上钩的时，才结束上调的动作，把鱼钓上来。
在内核将数据准备好之前，系统调用会一直等待所有的套接字，默认的是阻塞方式。
其实，我们例子中所说的鱼竿就是这一个文件描述符。这个模型是我们最常见的，程序调用和我们编写的基本程序是一致的。
程序的read必须在write之后执行，当write阻塞住了，read就不能执行下去，一直处于等待状态。
2.非阻塞IO（noblocking I/O）
B也在河边钓鱼，但是B不想将自己的所有时间都花费在钓鱼上，在等鱼上钩这个时间段中，B也在做其他的事情（一会看看书，一会读读报纸，一会又去看其他人的钓鱼等），但B在做这些事情的时候，每隔一个固定的时间检查鱼是否上钩。一旦检查到有鱼上钩，就停下手中的事情，把鱼钓上来。
其实，B在检查鱼竿是否有鱼，是一个轮询的过程。
每次客户询问内核是否有数据准备好，即文件描述符缓冲区是否就绪。当有数据报准备好时，就进行拷贝数据报的操作。当没有数据报准备好时，也不阻塞程序，内核直接返回未准备就绪的信号，等待用户程序的下一个轮询。
但是，轮询对于CPU来说是较大的浪费，一般只有在特定的场景下才使用。
3.信号驱动IO（signal blocking I/O）
C也在河边钓鱼，但与A、B不同的是，C比较聪明，他给鱼竿上挂一个铃铛，当有鱼上钩的时候，这个铃铛就会被碰响，C就会将鱼钓上来。
信号驱动IO模型，应用进程告诉内核：当数据报准备好的时候，给我发送一个信号，对SIGIO信号进行捕捉，并且调用我的信号处理函数来获取数据报。
4.IO多路复用（I/O multiplexing）
D同样也在河边钓鱼，但是D生活水平比较好，D拿了很多的鱼竿，一次性有很多鱼竿在等，D不断的查看每个鱼竿是否有鱼上钩。增加了效率，减少了等待的时间。
IO多路转接是多了一个select函数，select函数有一个参数是文件描述符集合，对这些文件描述符进行循环监听，当某个文件描述符就绪时，就对这个文件描述符进行处理。
其中，select只负责等，recvfrom只负责拷贝。
IO多路转接是属于阻塞IO，但可以对多个文件描述符进行阻塞监听，所以效率较阻塞IO的高。
5.异步IO（asynchronous I/O）
E也想钓鱼，但E有事情，于是他雇来了F，让F帮他等待鱼上钩，一旦有鱼上钩，F就打电话给E，E就会将鱼钓上去。
当应用程序调用aio_read时，内核一方面去取数据报内容返回，另一方面将程序控制权还给应用进程，应用进程继续处理其他事情，是一种非阻塞的状态。
当内核中有数据报就绪时，由内核将数据报拷贝到应用程序中，返回aio_read中定义好的函数处理程序。
很少有Linux系统支持，Windows的IOCP就是该模型。
具体可以看这篇：
https://blog.csdn.net/ZWE7616175/java/article/details/80591587
17、TCP断开连接
具体可以看这篇：
https://www.cnblogs.com/cenglinjinran/p/8482412.html
18、微服务有什么好处
1.独立的可扩展性，每个微服务都可以独立进行横向或纵向扩展，根据业务实际增长情况来进行快速扩展；
2.独立的可升级性，每个微服务都可以独立进行服务升级、更新，不用依赖于其它服务，结合持续集成工具可以进行持续发布，开发人员就可以独立快速完成服务升级发布流程；
3.易维护性，每个微服务的代码均只专注于完成该单个业务范畴的事情，因此微服务项目代码数量将减少至IDE可以快速加载的大小，这样可以提高了代码的可读性，进而可以提高研发人员的生产效率；
4.语言无关性，研发人员可以选用自己最为熟悉的语言和框架来完成他们的微服务项目（当然，一般根据每个公司的实际技术栈需要来了），这样在面对新技术或新框架的选用时，微服务能够更好地进行快速响应；
5.故障和资源的隔离性，在系统中出现不好的资源操作行为时，例如内存泄露、数据库连接未关闭等情况，将仅仅只会影响单个微服务；
6.优化跨团队沟通，如果要完全实践微服务架构设计风格，研发团队势必会按照新的原则来进行划分，由之前的按照技能、职能划分的方式变为按照业务（单个微服务）来进行划分，如此这般团队里将有各个方向技能的研发人员，沟通效率上来说要优于之前按照技能进行划分的组织架构；
7.原生基于“云”的系统架构设计，基于微服务架构设计风格，我们能构建出来原生对于“云”具备超高友好度的系统，与常用容器工具如Docker能够很方便地结合，构建持续发布系统与IaaS、PaaS平台对接，使其能够方便的部署于各类“云”上，如公用云、私有云以及混合云。
19、微服务有什么缺点
增加了系统复杂性
运维难度增加
本地调用变成RPC调用，有些操作会比较耗时
可能会引入分布式事务
20、Java实现单例模式
可以看这篇：
https://blog.csdn.net/fd2025/article/details/79711198
21、你认为，创建多少线程合适？
博客连接：https://www.jianshu.com/p/f30ee2346f9f
首先，我们有 CPU 密集型和 I/O 密集型两个场景，不同的场景当然需要的线程数也就不一样了。
对于CPU密集型程序， CPU 核数（逻辑）+ 1 个线程数是比较好的经验值的原因了
这是一个CPU核心的最佳线程数，如果多个核心，那么== I/O 密集型程序==的最佳线程数就是：
最佳线程数 = CPU核心数 * (1/CPU利用率) = CPU核心数 * (1 + (I/O耗时/CPU耗时))