面试题

序列化和json区别？

serialize在编码后大概是json的两倍。

原因：

• serialize后字符串包含了子串的长度，这可能是速度方面的优化，典型的空间换时间，但是它本身还是太重了。
• serialize有更加详细的类型区分，而json只有四种类型，并且是以简单的符号表示。

serialize的速度在大数据量的情况下比json差了快一个数量级。

从上面两点看，json不管是在速度还是在生成的字符串的大小上都比serialize要好，那为什么serialize还要存在呢？ 原因在下面这个点：实现的功能。

json无法处理对象方法等数据。

【使用范围】

• 序列化使用serialize，特别是对象的存储。这是其存在的意义。
• 与对象无关的数据存储可以使用json，如包含大量数字的数组等。只是当遇到这种情况，我们需要做的可能是重构数据库了。
• 数据交换时使用JSON，这也是其定义所在。
• 目前JSON是能用于UTF-8编码的数据。

新生代为什么要用标记复制算法

与标记-清除算法相比，复制算法是一种相对高效的回收方法。不适用于存活对象较多的场合，如老年代。

为什么需要 Survivor 空间。  我们看看如果没有 Survivor 空间的话，垃圾收集将会怎样进行：一遍新生代 gc 过后，不管三七二十一，活着的对象全部进入老年代，即便它在接下来的几次 gc 过程中极有可能被回收掉。这样的话老年代很快被填满， Full GC 的频率大大增加。总之，设置 Survivor 空间的目的是让那些中等寿命的对象尽量在 Minor GC 时被干掉，最终在总体上减少虚拟机的垃圾收集过程 对用户程序的影响。 

为什么2个 Survivor 空间可以达到要求？ 
       问题很清楚了，无论 Eden 和 Survivor 的比例怎么设置，在只有一个 Survivor 的情况下，总体上看在新生代空间满一半的时候就会触发一次 Minor GC 。

       那有没有提升的空间呢？比如说永远在新生代空间满 80% 的时候才触发 Minor GC ？ 
       事实上是可以做到的：我们可以设两个 Survivor 空间（ From Survivor 和 To Survivor ）。比如，我们把 Eden : From Survivor : To Survivor 空间大小设成 8 : 1 : 1 ，对象总是在 Eden 区出生， From Survivor 保存当前的幸存对象， To Survivor 为空。一次 gc 发生后： 
       1）Eden 区活着的对象 ＋ From Survivor 存储的对象被复制到 To Survivor ； 
       2) 清空 Eden 和 From Survivor ； 
       3) 颠倒 From Survivor 和 To Survivor 的逻辑关系： From 变 To ， To 变 From 。 

        可以看出，只有在 Eden 空间快满的时候才会触发 Minor GC 。而 Eden 空间占新生代的绝大部分，所以 Minor GC 的频率得以降低。当然，使用两个 Survivor 这种方式我们也付出了一定的代价，如 10% 的空间浪费、复制对象的开销等。

 

Redis分布式锁的正确实现方式

public class RedisTool {

    private static final String LOCK_SUCCESS = "OK";
    private static final String SET_IF_NOT_EXIST = "NX";
    private static final String SET_WITH_EXPIRE_TIME = "PX";

    /**
     * 尝试获取分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @param expireTime 超期时间
     * @return 是否获取成功
     */
    public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

        String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

        if (LOCK_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

    private static final Long RELEASE_SUCCESS = 1L;

    /**
     * 释放分布式锁
     * @param jedis Redis客户端
     * @param lockKey 锁
     * @param requestId 请求标识
     * @return 是否释放成功
     */
    public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {

        String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
        Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));

        if (RELEASE_SUCCESS.equals(result)) {
            return true;
        }
        return false;

    }

}

http性能优化的最佳实践

出发点：
1，努力消除或减少不必要的网络延迟。
2，将需要传输的数据压缩至最少。
性能优化实践：
1，减少DNS查找：每次主机名的解析都需要一次网络往返，从而增加了请求的延迟时间，同时还会阻塞后续的请求。
2，重用TCP连接：尽可能的使用持久连接，以消除因TCP握手和慢启动导致的延迟。
3，减少HTTP重定向。HTTP重定向需要额外的DNS查询、TCP握手等非常耗时，最佳的重定向次数为0.
4，使用CDN（内容分发网络）：把数据放在离用户地理位置更近的地方，可以明显减少每次TCP连接的网络延迟，增大吞吐量。
5，删除没有必要请求的资源。
6，在客户端缓存资源：缓存必要的应用资源，避免每次都重复请求相同的内容，例如多图片下载可以考虑使用缓存。
7，内容在传输前先压缩：传输数据之前应该先压缩应用资源，把要传输的字节减少到最小，在压缩的时候确保对每种不同的资源采用最好的压缩手段。
8，消除不必要的请求开销：减少请求的HTTP首部数据（比如HTTP cookie）.
9，并行处理请求和响应：请求和响应的派对都会导致延迟，可以尝试并行的处理请求和响应（利用多个HTTP1.1连接实现并行下载，在可能的情况下使用HTTP管道计数）。
10，针对协议版本采取优化措施。升级到HTTP2.0。

spring boot与spring mvc的区别是什么？

spring boot就是一个大框架里面包含了许许多多的东西，其中spring就是最核心的内容之一，当然就包含spring mvc。spring mvc 是只是spring 处理web层请求的一个模块。

说得更简便一些：Spring 最初利用“工厂模式”（DI）和“代理模式”（AOP）解耦应用组件。大家觉得挺好用，于是按照这种模式搞了一个 MVC框架（一些用Spring 解耦的组件），用开发 web 应用（ SpringMVC ）。然后有发现每次开发都写很多样板代码，为了简化工作流程，于是开发出了一些“懒人整合包”（starter），这套就是 Spring Boot。