Java面试：2021.05.26

1、SpringMVC跨域问题该如何配置？

springmvc4.2版本以上解决跨域问题只需要在controller中添加@CrossOrigin注解就可以解决跨域问题，前端正常发出ajxa请求的时候，返回数据中Access-Control-Allow-Origin的值就是前端的请求路径，最终思想就是需要服务器端一样遵循CORS标准，就可以实现同源策略原则。

2、怎么防止死锁？

首先我们了解一下什么情况下会发生死锁？

1.系统资源的竞争

通常系统中拥有的多个不可剥夺资源，其数量不足以满足多个进程运行的需要，使得进程再运行过程中，会因为争夺资源而陷入僵局，如磁带机，打印机等，只有对可不可剥夺资源的竞争，才会产生死锁，对可剥夺资源的竞争是不会引起死锁的

2.进程推进顺序非法

进程再运行过程中，请求和释放资源的顺续不当，导致死锁

3.死锁产生的必要条件

产生死锁必须同时满足四个条件，只要其中一个条件不成立，死锁就不会发生

1）互斥条件：进程要求对所分配的资源进行排他型控制，即在一段时间内，某个资源仅为一个进程所占有

2）不剥夺条件：进程所获得的资源在未使用完毕之前，不能被其他进程强行夺走，即只能 由获得该资源的进程自己来主动释放

3）请求和保持条件：进程已经保持了至少一个资源，但又提出了新的资源请求，而该资源 已被其他进程占有，此时请求进程被阻塞，但对自己已获得的资源保持不放

4）循环等待条件：存在一种进程资源的循环等待链，链中每一个进程已获得的资源同时被 链中下一个进程所请求。即存在一个处于等待状态的进程集合{Pl, P2, ..., pn}，其中Pi等 待的资源被P(i+1)占有（i=0, 1, ..., n-1)，Pn等待的资源被P0占有，

如何避免死锁？

1. 破坏”互斥”条件：系统里取消互斥、若资源一般不被一个进程独占使用，那么死锁是肯定不会发生的，但一般“互斥”条件是无法破坏的,因此，在死锁预防里主要是破坏其他三个必要条件，而不去涉及破坏“互斥”条件。

2. 破坏“请求和保持”条件：

方法1：所有的进程在开始运行之前，必须一次性的申请其在整个运行过程各种所需要的全部资源。

优点：简单易实施且安全。

缺点：因为某项资源不满足，进程无法启动，而其他已经满足了的资源也不会得到利用，严重降低了资源的利用率，造成资源浪费。

方法2：该方法是对第一种方法的改进，允许进程只获得运行初期需要的资源，便开始运行，在运行过程中逐步释放掉分配到，已经使用完毕的资源，然后再去请求新的资源。这样的话资源的利用率会得到提高，也会减少进程的饥饿问题。

3. 破坏“不剥夺”条件：当一个已经持有了一些资源的进程在提出新的资源请求没有得到满足时，它必须释放已经保持的所有资源，待以后需要使用的时候再重新申请。这就意味着进程已占有的资源会被短暂的释放或者说被抢占了。

4. 破坏“循环等待”条件：可以通过定义资源类型的线性顺序来预防，可以将每个资源编号，当一个进程占有编号为i 的资源时，那么它下一次申请资源只能申请编号大于i 的资源。

3、Jsp有哪些内置对象,它们的作用分别是什么?

1.request对象 -> 客户端的请求信息被封装在request对象中。 2.response对象 -> 服务端响应的信息被封装在response对象中。 3.session对象 -> session指客户端与服务端的一次会话。 4.out对象 -> 是向客户端输出内容的常用对象。 5.page对象 -> 当前Jsp页面本身。 6.application对象 -> application实现了用户间数据的共享,可以存放全局变量。 7.exception对象 -> 当一个页面在运行过程中发生了意外就使用此对象,前提是isError属性为true。 8.pageContext对象 -> 提供了Jsp页面内所有的对象的访问。 9.config对象 -> config对象是Servlet初始化时候封装参数用到的对象。

4、说几个你常见的linux命令？    

• top - 查看进程的 cpu 占用
• ps -aux | grep 进程关键字，经常用来获取进程 pid
• netstat -tnlp 查看端口的占用情况
• systemctl 管理服务

5、elasticsearch 索引数据多了怎么办，如何调优，部署？

1、动态索引层面

基于模板+时间+rollover api滚动创建索引，举例：设计阶段定义：blog索引的模板格式为：blog_index_时间戳的形式，每天递增数据。

这样做的好处：不至于数据量激增导致单个索引数据量非常大，接近于上线2的32次幂-1，索引存储达到了TB+甚至更大。

一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑+及早避免。

2、 存储层面

冷热数据分离存储，热数据（比如最近3天或者一周的数据），其余为冷数据。对于冷数据不会再写入新数据，可以考虑定期force_merge加shrink压缩操作，节省存储空间和检索效率。

3、部署层面

一旦之前没有规划，这里就属于应急策略。结合ES自身的支持动态扩展的特点，动态新增机器的方式可以缓解集群压力，注意：如果之前主节点等规划合理，不需要重启集群也能完成动态新增的。

6、throw 和 throws 的区别是什么？

throw：

• 表示方法内抛出某种异常对象
• 如果异常对象是非 RuntimeException 则需要在方法申明时加上该异常的抛出,即需要加上throws语句或者在方法体内 try catch 处理该异常，否则编译报错
• 执行到 throw 语句则后面的语句块不再执行

throws：

• 方法的定义上使用 throws 表示这个方法可能抛出某种异常
• 需要由方法的调用者进行异常处理

7、Zookeeper 怎么保证主从节点的状态同步？

Zookeeper 的核心是原子广播机制，这个机制保证了各个 server 之间的同步。实现这个机制的协议叫做 Zab 协议。Zab 协议有两种模式，它们分别是恢复模式和广播模式。

1. 恢复模式

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数 server 完成了和 leader 的状态同步以后，恢复模式就结束了。状态同步保证了 leader 和 server 具有相同的系统状态。

1. 广播模式

一旦 leader 已经和多数的 follower 进行了状态同步后，它就可以开始广播消息了，即进入广播状态。这时候当一个 server 加入 ZooKeeper 服务中，它会在恢复模式下启动，发现 leader，并和 leader 进行状态同步。待到同步结束，它也参与消息广播。ZooKeeper 服务一直维持在 Broadcast 状态，直到 leader 崩溃了或者 leader 失去了大部分的 followers 支持。

8、zk 节点宕机如何处理？

Zookeeper 本身也是集群，推荐配置不少于 3 个服务器。Zookeeper 自身也要保证当一个节点宕机时，其他节点会继续提供服务。

如果是一个 Follower 宕机，还有 2 台服务器提供访问，因为 Zookeeper 上的数据是有多个副本的，数据并不会丢失；

如果是一个 Leader 宕机，Zookeeper 会选举出新的 Leader。