【Java】几道让你拿offer的面试题

前言

只有光头才能变强

之前在刷博客的时候，发现一些写得比较好的博客都会默默收藏起来。最近在查阅补漏，有的知识点比较重要的，但是在之前的博客中还没有写到，于是趁着闲整理一下。

文本的知识点：

  • Integer常量池
  • TCP拆包粘包
  • select、poll、epoll简单区别
  • jdk1.6以后对Synchronize锁优化
  • Java内存模型

本文力求简单讲清每个知识点，希望大家看完能有所收获

一、神奇的Integer

前阵子在群上看有人在讨论关于Integer的true或者false问题，我本以为我已经懂了这方面的知识点了。但还是做错了，后来去请教了一下朋友。朋友又给我发了另一张图：

image

后来发现这是出自《深入理解Java虚拟机——JVM高级特性与最佳实践(第2版)》中的10.3.2小节中~


public class Main_1 {
    public static void main(String[] args) {
        Integer a = 1;
        Integer b = 2;
        Integer c = 3;
        Integer d = 3;
        Integer e = 321;
        Integer f = 321;
        Long g = 3L;
        System.out.println(c == d);
        System.out.println(e == f);
        System.out.println(c == (a + b));
        System.out.println(c.equals(a + b));
        System.out.println(g == (a + b));
        System.out.println(g.equals(a + b));
        System.out.println(g.equals(a + h));
    }

}

你们可以先思考一下再往下翻看答案，看看能不能做对。

1.1解题思路

在解这道题之前，相信很多人都已经知道了，在Java中会有一个Integer缓存池，缓存的大小是：-128~127

image

答案是：

  • true
  • false
  • true
  • true
  • true
  • false
  • true

简单解释一下：

  • 使用==的情况：
    • 如果比较Integer变量，默认比较的是地址值。
    • Java的Integer维护了从-128~127的缓存池
    • 如果比较的某一边有操作表达式(例如a+b)，那么比较的是具体数值
  • 使用equals()的情况：
    • 无论是Integer还是Long中的equals()默认比较的是数值。
    • Long的equals()方法，JDK的默认实现：会判断是否是Long类型
  • 注意自动拆箱，自动装箱问题。
image

反编译一下看看：


import java.io.PrintStream;

public class Main_1 {
    public static void main(String[] paramArrayOfString) {
        Integer localInteger1 = Integer.valueOf(1);
        Integer localInteger2 = Integer.valueOf(2);
        Integer localInteger3 = Integer.valueOf(3);
        Integer localInteger4 = Integer.valueOf(3);
        Integer localInteger5 = Integer.valueOf(321);
        Integer localInteger6 = Integer.valueOf(321);
        Long localLong = Long.valueOf(3L);

        // 缓存池
        System.out.println(localInteger3 == localInteger4);
        
        // 超出缓存池范围
        System.out.println(localInteger5 == localInteger6);
        
        // 存在a+b数值表达式，比较的是数值
        System.out.println(localInteger3.intValue() == localInteger1.intValue() + localInteger2.intValue());

        // equals比较的是数值
        System.out.println(localInteger3.equals(Integer.valueOf(localInteger1.intValue() + localInteger2.intValue())));
        // 存在a+b数值表达式，比较的是数值
        System.out.println(localLong.longValue() == localInteger1.intValue() + localInteger2.intValue());
        // Long的equals()先判断传递进来的是不是Long类型，而a+b自动装箱的是Integer类型
        System.out.println(localLong.equals(Integer.valueOf(localInteger1.intValue() + localInteger2.intValue())));

        // ... 最后一句在这里漏掉了，大家应该可以推断出来
    }
}

我使用的反编译工具是jd-gui，如果还没有试过反编译的同学可以下载来玩玩：

二、Synchronize锁优化手段有哪些

多线程文章回顾：

之前在写多线程文章的时候，简单说了一下synchronized锁在jdk1.6以后会有各种的优化：适应自旋锁，锁消除，锁粗化，轻量级锁，偏向锁。

image

本以为这些优化是非常难以理解的东西，其实不然~~~简单了解一下还是很好理解的。

2.1适应自旋锁

锁竞争是kernal mode下的，会经过user mode(用户态)到kernal mode(内核态) 的切换，是比较花时间的。

自旋锁出现的原因是人们发现大多数时候锁的占用只会持续很短的时间，甚至低于切换到kernal mode所花的时间，所以在进入kernal mode前让线程等待有限的时间，如果在此时间内能够获取到锁就避免了很多无谓的时间，若不能则再进入kernal mode竞争锁。

在JDK 1.6中引入了自适应的自旋锁，说明自旋的时间不固定，要不要自旋变得越来越聪明。

自旋锁在JDK1.4.2中就已经引入，只不过默认是关闭的，可以使用-XX：+UseSpinning参数来开启，在JDK1.6中就已经改为默认开启了。

参考资料：

2.2锁消除

如果JVM明显检测到某段代码是线程安全的(言外之意：无锁也是安全的)，JVM会安全地原有的锁消除掉！

比如说：


    public void vectorTest(){
        Vector<String> vector = new Vector<String>();
        for(int i = 0 ; i < 10 ; i++){
            vector.add(i + "");
        }

        System.out.println(vector);
    }

Vector是默认加锁的，但JVM如果发现vector变量仅仅在vectorTest()方法中使用，那该vector是线程安全的。JVM会把vector内部加的锁去除，这个优化就叫做：锁消除。

2.3锁粗化

默认情况下，总是推荐将同步块的作用范围限制得尽量小。

但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作是出现在循环体中的，频繁地进行互斥同步操作也会导致不必要的性能损耗。

JVM会将加锁的范围扩展(粗化)，这就叫做锁粗化。

2.4轻量级锁

轻量级锁能提升程序同步性能的依据是“对于绝大部分的锁，在整个同步周期内都是不存在竞争的”，这是一个经验数据。

  • 如果没有竞争，轻量级锁使用CAS操作避免了使用互斥量的开销
  • 但如果存在锁竞争，除了互斥量的开销外，还额外发生了CAS操作，因此在有竞争的情况下，轻量级锁会比传统的重量级锁更慢。

简单来说：如果发现同步周期内都是不存在竞争，JVM会使用CAS操作来替代操作系统互斥量。这个优化就被叫做轻量级锁。

2.5偏向锁

偏向锁就是在无竞争的情况下把整个同步都消除掉，连CAS操作都不做了！

偏向锁可以提高带有同步但无竞争的程序性能。它同样是一个带有效益权衡（Trade Off）性质的优化，也就是说，它并不一定总是对程序运行有利，如果程序中大多数的锁总是被多个不同的线程访问，那偏向模式就是多余的。在具体问题具体分析的前提下，有时候使用参数-XX：-UseBiasedLocking来禁止偏向锁优化反而可以提升性能。

2.6简单总结各种锁优化

  • 自适应偏向锁：自旋时间不固定
  • 锁消除：如果发现代码是线程安全的，将锁去掉
  • 锁粗化：加锁范围过小(重复加锁)，将加锁的范围扩展
  • 轻量级锁：在无竞争的情况下使用CAS操作去消除同步使用的互斥量
  • 偏向锁：在无竞争环境下，把整个同步都消除，CAS也不做。

参考资料：

三、TCP粘包，拆包

这是在看wangjingxin大佬面经的时候看到的面试题，之前对TCP粘包，拆包没什么概念，于是就简单去了解一下。

3.1什么是拆包粘包？为什么会出现？

在进行Java NIO学习时，可能会发现：如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况。

TCP的首部格式：

image
  • TCP是基于字节流的，虽然应用层和TCP传输层之间的数据交互是大小不等的数据块，但是TCP把这些数据块仅仅看成一连串无结构的字节流，没有边界；
  • 从TCP的帧结构也可以看出，在TCP的首部没有表示数据长度的字段

基于上面两点，在使用TCP传输数据时，才有粘包或者拆包现象发生的可能。

一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包

image

接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包

image

拆包和粘包的问题导致接收端在处理的时候会非常困难(因为无法区分一个完整的数据包)

3.2解决拆包和粘包

分包机制一般有两个通用的解决方法：

  • 1,特殊字符控制
  • 2,在包头首都添加数据包的长度

如果使用netty的话，就有专门的编码器和解码器解决拆包和粘包问题了。

tips:UDP没有粘包问题，但是有丢包和乱序。不完整的包是不会有的，收到的都是完全正确的包。传送的数据单位协议是UDP报文或用户数据报，发送的时候既不合并，也不拆分。

参考资料

四、select、poll、epoll简单区别

NIO回顾：

在Linux下它是这样子实现I/O复用模型的：

调用select/poll/epoll其中一个函数，传入多个文件描述符，如果有一个文件描述符就绪，则返回，否则阻塞直到超时。

这几个函数是有些区别的，可能有的面试官会问到这三个函数究竟有什么区别：

区别如下图：

image

两句话总结：

  • select和poll都需要轮询每个文件描述符，epoll基于事件驱动，不用轮询
  • select和poll每次都需要拷贝文件描述符，epoll不用
  • select最大连接数受限，epoll和poll最大连接数不受限

tips:epoll在内核中的实现，用红黑树管理事件块

4.1通俗例子

现在3y在公司里边实习，写完的代码需要给测试测一遍。

select/poll情况：

  • 开发在写代码，此时测试挨个问所有开发者，你写好程序了没有？要测试吗？

epoll情况：

  • 开发写完代码了，告诉测试：“我写好代码了，你去测测，功能是XXX”。于是测试高高兴兴去找bug了。

其他通俗描述[1]：

一个酒吧服务员（一个线程），前面趴了一群醉汉，突然一个吼一声“倒酒”（事件），你小跑过去给他倒一杯，然后随他去吧，突然又一个要倒酒，你又过去倒上，就这样一个服务员服务好多人，有时没人喝酒，服务员处于空闲状态，可以干点别的玩玩手机。至于epoll与select，poll的区别在于后两者的场景中醉汉不说话，你要挨个问要不要酒，没时间玩手机了。io多路复用大概就是指这几个醉汉共用一个服务员。

来源：

其他通俗描述[2]：

简单举个例子（可能也不是很形象）select/poll饭店服务员（内核）告诉饭店老板（用户程序）：”现在有客人结账“但是这个服务员没人明确告诉老板，哪几桌的客人结帐。老板得自儿一个一个桌子去问：请问是你要结帐？epoll饭店服务员（内核）告诉饭店老板（用户程序）：”1,2,5号客人结账“老板就可以直接去1,2,5号桌收钱了

来源：

深入了解参考资料：

五、Java内存模型

JVM博文回顾：

之前在写JVM的时候，还一度把JVM内存结构与Java内存模型给搞混了~~~还好有热心的网友给我指出来。

JVM内存结构：

image

Java内存模型：

image

操作变量时的规则：

  • Java内存模型规定了所有的变量都存储在主内存
  • 线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝
  • 线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的变量

从工作内存同步回主内存实现是通过以下的8种操作来完成：

  • lock（锁定）：作用于主内存的变量，把一个变量标识为一条线程独占状态。
  • unlock（解锁）：作用于主内存变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定。
  • read（读取）：作用于主内存变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
  • load（载入）：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中。
  • use（使用）：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
  • assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋值给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
  • store（存储）：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作。
  • write（写入）：作用于主内存的变量，它把store操作从工作内存中一个变量的值传送到主内存的变量中。

Java内存模型是围绕着在并发过程中如何处理原子性、可见性和有序性这3个特征来建立的

保证原子性的操作：

  • read、load、assign、use、store和write
  • synchronized锁

保证有序性(重排序导致无序)的操作：

  • volatile
  • synchronized锁

保证可见性：

  • volatile
  • synchronized锁
  • final

在上面也说了，有序性可以通过volatile和synchronized锁来保证，但我们一般写程序的时候不会总是关注代码的有序性的。其实，我们Java内部中有一个原则，叫做先行发生原则(happens-before)

  • “先行发生”（happens-before）原则可以通过：几条规则一揽子地解决并发环境下两个操作之间是否可能存在冲突的所有问题
  • 有了这些规则，并且我们的操作是在这些规则定义的范围之内。我们就可以确保，A操作肯定比B操作先发生(不会出现重排序的问题)

“先行发生”（happens-before）原则有下面这么几条：

  • 程序次序规则（Program Order Rule）：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作。准确地说，应该是控制流顺序而不是程序代码顺序，因为要考虑分支、循环等结构。
  • 管程锁定规则（Monitor Lock Rule）：一个unlock操作先行发生于后面对同一个锁的lock操作。这里必须强调的是同一个锁，而“后面”是指时间上的先后顺序。
  • volatile变量规则（Volatile Variable Rule）：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的“后面”同样是指时间上的先后顺序。线程启动规则（Thread Start Rule）：Thread对象的start（）方法先行发生于此线程的每一个动作。
  • 线程终止规则（Thread Termination Rule）：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过Thread.join（）方法结束、Thread.isAlive（）的返回值等手段检测到线程已经终止执行。
  • 线程中断规则（Thread Interruption Rule）：对线程interrupt（）方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted（）方法检测到是否有中断发生。
  • 对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize（）方法的开始。
  • 传递性（Transitivity）：如果操作A先行发生于操作B，操作B先行发生于操作C，那就可以得出操作A先行发生于操作C的结论。

参考资料：

六、最后

本文简单整理了一下在学习中做的笔记，还有在网上遇到一些比较重要的知识点(面试题)~希望大家看完能有所收益。

参考资料：

  • 《深入理解Java虚拟机——JVM高级特性与最佳实践(第2版)》

如果大家有更好的理解方式或者文章有错误的地方还请大家不吝在评论区留言，大家互相学习交流~~~

如果想看更多的原创技术文章，欢迎大家关注我的微信公众号:Java3y。Java技术群讨论：742919422。公众号还有海量的视频资源哦，关注即可免费领取。

可能感兴趣的链接：

©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 206,482评论 6赞 481
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 88,377评论 2赞 382
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 152,762评论 0赞 342
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 55,273评论 1赞 279
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 64,289评论 5赞 373
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 49,046评论 1赞 285
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,351评论 3赞 400
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,988评论 0赞 259
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 43,476评论 1赞 300
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,948评论 2赞 324
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,064评论 1赞 333
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,712评论 4赞 323
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,261评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,264评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,486评论 1赞 262
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 45,511评论 2赞 354
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,802评论 2赞 345

推荐阅读更多精彩内容

  • 面试知识点1
    Java8张图 11、字符串不变性 12、equals()方法、hashCode()方法的区别 13、...
    Miley_MOJIE阅读 3,693评论 0赞 11
  • 谢谢你
    走在路上 忽然发现 无论未来怎样 我都会在某一天看着你的眼睛 真诚地说一声 谢谢你 是你 让我的生活不再暗淡无光 ...
    晨宁Chinadoll阅读 210评论 0赞 1
  • 她光温宁
    《她光温宁》 ——瓦十三 我思索着， 一如从前每一个发呆的时刻， 灵魂悄做手脚， 从静谧中抽出一丝念想， 拽着胸怀...
    瓦十三阅读 108评论 0赞 0