JAVA秋招面试题精选-第一天总结

目录

分栏简介：

问题一：订单表每天新增500W条数据，分库分表应该怎么设计？

问题难度以及频率：

问题导向：

满分答案：

举一反三：

问题总结：

问题二：解释一下JAVA的内存模型和happens-before的规则？

问题难度以及频率：

问题导向：

满分答案：

举一反三：

问题总结：

---

分栏简介：

        欢迎来到我的“面试”专栏！在这里，我精心记录并分享各类面试中的高频问题及深度解析。无论你是即将步入职场的应届生，还是寻求跳槽晋升的职场人，都能在这里找到宝贵的面试经验和答题技巧。从编程基础到算法难题，从项目管理到行业趋势，每一篇文章都力求让你在面试中更加游刃有余。关注我，让我们一起在面试之路上步步为赢，迈向职业生涯的新高峰！

问题一：订单表每天新增500W条数据，分库分表应该怎么设计？

问题难度以及频率：

 ✮  ✮  ✮  ✮  

问题导向：

        面试官问这个问题的意图很明显，就是考察你对分库分表的理解，特别是多增加了两个条件，涉及到多个分片键查询的问题，给求职者失职了一定的困难。更重要的是，每天有500万的增量数据，一个月就有1.5个亿，数据库单表支撑一亿数据的快速检索，性能上一定是很差的。

        要注意，这种没有边界的问题，主要是考察求职者的思路，解决方案能不能落地不重要，下面我们来看看这和问题的解决思路

满分答案：

        这个问题要从两个方面来回答：第一个部分就是分库分表的方案，分库分表很简单，但是要分多少个表多少个库，是要做好提前的规划的，由于数据的增量比较大，我们要避免分库分表之后，又出现容量满了的情况，或者单表数据量过大的问题，如果这个时候再去做容量扩充，数据迁移和扩容的成本会非常高。

        一天500万的增量，一年大概有18亿的数据量，我们按照保留两年的热数据量，大概就是接近40亿，然后我们做一些空间的预留，算50亿的数据，那我们可以按照32个库，每个库32张表来规划，一共1024张表， 每个表里面存放500万数据量，那么就可以满足50亿数据的容量规划。

        在这个方案中，我们可以选择orderID作为分片键，采用一致性hash算法来进行路由，在性能层面，假设每个库正常写入的并发量是1000，那32个库可以承载32000的并发量。如果每个库的写性能再优化到1500.就意味着这个方案能支持接近5W每秒的写并发，这个已经能够满足大部分互联网公司的并发需求了。

举一反三：

        需要考虑的问题，这个方案并不能完整的满足面试官的需求，还有几个问题需要考虑：* 业务需要根据用户ID进行查找，而用户ID不是分片键，导致查询的时候变得很复杂。

        对于这样的问题，我们可以采用基因算法，来确保用户ID对应的订单ID路由到同一个何库或者同一个表，在生成订单ID的时候，把用户ID的基因片段拼接到订单ID中，从而保证不管是通过订单ID查询还是根据用户ID进行查询都能路由到同一个表中。

        第二、虽然我们设计了32个库和32个表，但是也只能存储50亿的数据，也就是差不多三年时间，那三年之后这个方案就不满足了，该怎么办呢？

        通常订单类的业务，我们频繁访问的数据一般在一年以内，超过一年的数据基本就不用太关心了，所以我们可以设计冷热数据分离的方案，热数据保持一年，一年以后得数据迁移到历史库，历史库也就是冷库，只保存两年，超过这个时间的数据直接归档，从而实现一个1+2的数据存储方案。

问题总结：

        除了以上的方案，我们还可以采取如今比较主流的HTAP存储方案，比如TIDB、PolorDB等，这类数据库的好处是可以支持在线扩容，比如分片、迁移，这种扩展对业务完全无感知，同时支持强一致性的分布事务的方案，也就是跨分片跨节点的事务一致性，可以跨机房部署实现跨机房容灾，支持多节点写入。

问题二：解释一下JAVA的内存模型和happens-before的规则？

问题难度以及频率：

 ✮  ✮  ✮  ✮  ✮ 

问题导向：

        面试官考察这个问题，主要是考察你对Java多线程、并发控制、内存模型以及数据同步等底层原理的理解，他们希望看到的是你对这些复杂概念的深入理解，和能够清晰表述的能力，以此来评估你在实际工作中处理并发问题的能力。

        在回答这个问题的时候，你不仅要能够清晰地表述JMM和happens-before的规则，还应该能够举例说明这些概念如何在实际编程中去使用，并解决并发问题。

满分答案：

        Java内存模型主要定义了Java虚拟机在计算机内存中的工作方式，JVM决定了一个线程对共享变量的写入，何时对另外一个线程可见，happens-before规则，他是一个能够帮助我们理解内存可见性和有序性的一个原则。

        如果操作A，happens-before操作B,那么A的结果必须对B可见，而A的执行顺序应该在B之前，这个规则可以帮助我们确保在多线程开发中没有额外的同步情况下，不会读取到旧的数据，也就是不会产生可见性问题。

        Happens-before规则有很多，下面举几个常见的规则：

        1. 程序顺序规则，在单线程环境中，按照代码的顺序，书写在前面的操作happens-before于书写在后面的操作。

        2. 同步锁规则，对一个锁的释放，一定happens-before于随后对这个锁的加锁操作。

        3. volatile变量规则，对一个volatile变量的写的操作happens-before于任意后续对这个volatile变量的读的操作。

        4. 传递性规则，如果A happens-before B，且B happens-before C，那么A一定happens-before于C。

        以上就是常见的happens-before的操作原则

举一反三：

        Java内存模型也就是JMM，它主要关注的是多线程环境下，如何以安全的方式在主内存和工作内存之间交换信息，我们都知道Java程序是运行在Java虚拟机上的，同时我们也知道JVM是一个跨语言跨平台的实现，也就是Write Once、Run Anywhere。

        那么JVM是如何实现在不同平台上都达到线程安全这样一个目的的呢？所以这个时候JMM的概念就出来了，Java内存模型也就是Java member model，就是一种符合内存模型规范的，屏蔽了各种硬件和操作系统的访问差异的，保证了Java程序在各种平台下对内存的访问都能保证效果一致的机制及规范。

        Java内存模型规定的所有变量都存储在总内存中，每条线程有自己的工作内存，线程的工作内存中，保存了这个线程中用到的变量的主内存的副本拷贝，线程对变量的所有操作，都必须在工作内存中进行，而不能直接读写主内存。

        不同的线程之间也无法直接访问对方工作内存中的变量，线程之间的变量传输，都需要通过主内存进行一个同步，而happen-before规则是Java内存中定义的一种可见性和有序性关系的一个模型，它用来描述两个操作的先后执行顺序。

问题总结：

        面试中，关于Java内存模型（JMM）及happens-before规则的考察，重点在于理解多线程环境下内存访问的安全性和一致性。要清晰阐述JMM的工作原理和happens-before规则，并能举例说明其在解决并发问题中的应用，以展现对并发控制的深入理解。

如果文章对您有帮助，还请您点赞支持
感谢您的阅读，更多问题请关注博主后续更新