JDK9引入了AOT编译模式。

AOT 有什么优点？适用于什么场景？

JDK 9 引入了一种新的编译模式 AOT(Ahead of Time Compilation) 。
和 JIT 不同的是，这种编译模式会在程序被执行前就将其编译成机器码，属于静态编译（C、 C++，Rust，Go 等语言就是静态编译）。

AOT 避免了 JIT 预热等各方面的开销，可以提高 Java 程序的启动速度。并且AOT 还能减少内存占用和增强 Java 程序的安全性，特别适合云原生场景。具体如下：

• 启动速度：云原生应用通常需要快速启动和停止，以实现资源的动态分配和弹性伸缩。AOT编译可以显著减少应用程序的启动时间。
• 资源效率：在云环境中，资源的使用效率非常重要。AOT减少了内存占用，因为它们不需要在运行时进行编译和优化，这有助于降低云服务的成本。
• 安全性：AOT编译的代码通常是难以被反编译的，这增加了应用程序的安全性。在云环境中，安全性是一个重要的考虑因素，因为多个应用程序可能会共享相同的物理硬件。
• 可预测性：AOT编译提供了更可预测的性能，因为所有的优化都在编译时完成，不会在运行时发生变化。这对于需要稳定性能的云服务来说非常重要。
• 容器化和微服务：云原生应用通常采用容器化和微服务架构。AOT编译的应用程序可以更容易地打包到容器中，因为它们不需要在运行时进行额外的编译步骤。

AOT和JIT的对比和区别

JIT 与 AOT 两者的关键指标对比如下:

可以看出，AOT 的主要优势在于启动时间、内存占用和打包体积。JIT 的主要优势在于具备更高的极限处理能力，可以降低请求的最大延迟（这两点主要都是因为它可以动态优化代码还有逃逸分析机制）。

为什么不全部使用 AOT 呢？

既然 AOT 这么多优点，那为什么不全部使用这种编译方式呢？只能说 AOT 更适合当下的云原生场景，对微服务架构的支持也比较友好。除此之外，AOT 编译无法支持 Java 的一些动态特性，如反射、动态代理、动态加载等。然而，很多框架和库（如 最常用的Spring 和 Springboot）都用到了这些特性。如果只使用 AOT 编译，那就没办法使用这些框架和库了，为了支持类似的动态特性，所以选择使用 JIT 即时编译器。

逃逸分析和对象存储在堆上的关系。

为什么说是几乎所有对象实例都存在于堆中呢？ 这是因为 HotSpot 虚拟机引入了 JIT 优化之后，会对对象进行逃逸分析，如果发现某一个对象并没有逃逸到方法外部（是否会作为参数传递给其他方法，或者被外部方法访问），那么就可能通过标量替换来实现栈上分配，而避免堆上分配内存。

标量替换实现栈上分配，避免堆上分配的意思是指：将对象分解成若干个标量（即基本数据类型的值，如 int、float 等），然后这些标量可以直接存储在栈上，而不是作为一个完整的对象存储在堆上。这样做的好处是，当方法调用结束时，这些标量会随着栈帧的销毁而自动释放，从而避免了在堆上进行分配和垃圾回收的开销。

高并发中的集合有哪些问题?

第一代线程安全集合类
Vector、Hashtable
是怎么保证线程安排的：使用synchronized修饰方法
缺点：效率低下

第二代线程非安全集合类
ArrayList、HashMap
线程不安全，但是性能好，用来替代Vector、.Hashtable
使用ArrayList、HashMap,需要线程安全怎么办呢？
Collections.synchronizedList(list);Collections.synchronizedMap(m);
底层使用synchronized代码块锁，虽然也是锁住了所有的代码，但是锁在方法里边，比锁在方法外边性能可以理解为稍有提高吧。毕竟进方法本身就要分配资源的

第三代线程安全集合类
在大量并发情况下如何提高集合的效率和安全呢？
java.util.concurrent.*
ConcurrentHashMap:
CopyOnWriteArrayList
CopyOnWriteArraySet:注意不是CopyOnWriteHashSet*

底层大都采用Lock锁(1.8的ConcurrentHashMap不使用Lock锁)，保证安全的同时，性能也很高。