如果当时这16道题能答好，现在应该已经被录取了（记一次面试的亲身经历 2020-9-9）

关注

原创最新推荐文章于 2026-02-11 00:23:08 发布 5.5k 阅读 AI 写同款· GEO 优化 ›

海思Hi3516CV610--SPI NAND Flash移植实战：从手册到驱动的完整适配本文详细介绍了海思Hi3516CV610芯片上SPI NAND Flash的移植实战，包括从手册解读到驱动适配的完整流程。以GD5F2GM7UEYIGR Flash为例，重点讲解了关键参数确认、模式选择、时序配置以及U-Boot和Linux内核驱动的具体实现步骤，帮助开发者快速完成Flash移植工作。阅读详情

前情提要

9月9日参加面试遇到的问题，10天时间，历经14次编辑，今天（9月19日）才整理出来，知识的匮乏，不言而喻。

今天无意之间看到了这个，果断申请了，希望优快云能给我一次机会，让我更多的参与进来，提高自己，成为博客专家，成为高薪全栈工程师，公司顶梁柱。

之前的优快云首页无外乎三点

标题党，所谓的面试题，今天阿里，明天字节跳动的，也不知道你到底去哪里了。
Python，也不知道有多少干Python的，java都是hello world，你们呢？直接爬美女图片，吸引眼球？目的达到了，你赢了。
一些大佬的博客，这才是重点，优快云所需要的，但是感觉有一个弊端，也许同样的博客，大佬的就访问量破万，小菜的基本全都石沉大海。

之前我也有一段时间，做起了标题党，效果不是很好；

我也插入一些美女图片，你还真别说，效果还是有的；

但，这不应该是一个高手所为，我也反思了自己，觉得还是应该坚持本心，写博客是为了学习，不是为了哗众取宠。

《如果当时》系列博客，是基于自己真实的面试经历，全部都是面试真题，血和泪的教训，分享给大家，希望能给那些和我有同样困扰的人，提供一些帮助，努力一定就会有收获，加油。

一、ArrayList 和 Vector 的区别是什么？

Vector 使用了 Synchronized 来实现线程同步，是线程安全的，而 ArrayList 是非线程安全的。
ArrayList 和 Vector 都会根据实际的需要动态的调整容量，只不过在 Vector 扩容每次会增加 1 倍，而 ArrayList 只会增加 50%。
在不考虑并发问题的时候还是推荐使用Arraylist。

二、Array 和 ArrayList 有何区别？

Array可以包含基本类型和对象类型，ArrayList只能包含对象类型。
Array大小是固定的，ArrayList的大小是动态变化的。
ArrayList提供了更多的方法和特性，比如：addAll()，removeAll()，iterator()等等。
对于基本类型数据，ArrayList 使用自动装箱来减少编码工作量；而当处理固定大小的基本数据类型的时候，这种方式相对比较慢，这时候应该使用Array。

三、除了 ReetrantLock，你还接触过 JUC 中的哪些并发工具？

我的答案：

ReetrantWriteReadLock:读写锁，包含读取和写入两种类型的锁，当进行读取操作时允许多线程访问，当进行写操作时，只允许一个线程访问；
ConcurrentHashMap:HashMap的同步版本，HashTable的升级版本，HashTable会锁住整个集合，而ConcurrentHashMap只是锁住当前访问的键值对；
Vector：Vector中加入了Synchronized锁，是线程安全的；相对于Arraylist，因为加锁的原因Vector效率要低一点；vector是1倍扩容，ArrayList是50%扩容；
Volatile：只能修饰变量，不能修饰代码块和方法，保证了可见性和有序性，不能保证原子性；

百度答案：

juc下常用的五个高并发工具：

CountDownLatch:同步计数器
CyclicBarrier: 线程屏障的功能
Exchanger：用来使两个线程交换数据。
Semaphore：控制信号量的个数，构造时传入个数。总数就是控制并发的数量。
Future：接口，FutureTask是它的实现类，配合线程池来一起工作，将任务交给线程池去处理。

百度的和我想的完全不是一回事，有时间再看看JUC吧！

四、请谈谈 ReadWriteLock 和 StampedLock。

1、ReadWriteLock

ReadWriteLock 可以实现多个读锁同时进行，但是读与写和写于写互斥，只能有一个写锁线程在进行。

2、StampedLock

StampedLock是Jdk在1.8提供的一种读写锁，相比较ReentrantReadWriteLock性能更好，因为ReentrantReadWriteLock在读写之间是互斥的，使用的是一种悲观策略，在读线程特别多的情况下，会造成写线程处于饥饿状态，虽然可以在初始化的时候设置为true指定为公平，但是吞吐量又下去了，而StampedLock是提供了一种乐观策略，更好的实现读写分离，并且吞吐量不会下降。

StampedLock包括三种锁：

（1）写锁writeLock：

writeLock是一个独占锁写锁，当一个线程获得该锁后，其他请求读锁或者写锁的线程阻塞，获取成功后，会返回一个stamp（凭据）变量来表示该锁的版本，在释放锁时调用unlockWrite方法传递stamp参数。提供了非阻塞式获取锁tryWriteLock。

（2）悲观读锁readLock：

readLock是一个共享读锁，在没有线程获取写锁情况下，多个线程可以获取该锁。如果有写锁获取，那么其他线程请求读锁会被阻塞。悲观读锁会认为其他线程可能要对自己操作的数据进行修改，所以需要先对数据进行加锁，这是在读少写多的情况下考虑的。请求该锁成功后会返回一个stamp值，在释放锁时调用unlockRead方法传递stamp参数。提供了非阻塞式获取锁方法tryWriteLock。

（3）乐观读锁tryOptimisticRead：

tryOptimisticRead相对比悲观读锁，在操作数据前并没有通过CAS设置锁的状态，如果没有线程获取写锁，则返回一个非0的stamp变量，获取该stamp后在操作数据前还需要调用validate方法来判断期间是否有线程获取了写锁，如果是返回值为0则有线程获取写锁，如果不是0则可以使用stamp变量的锁来操作数据。由于tryOptimisticRead并没有修改锁状态，所以不需要释放锁。这是读多写少的情况下考虑的，不涉及CAS操作，所以效率较高，在保证数据一致性上需要复制一份要操作的变量到方法栈中，并且在操作数据时可能其他写线程已经修改了数据，而我们操作的是方法栈里面的数据，也就是一个快照，所以最多返回的不是最新的数据，但是一致性得到了保证。

五、说一下 session 的工作原理？

当客户端登录完成后，会在服务端产生一个session，此时服务端会将sessionid返回给客户端浏览器。客户端将sessionid储存在浏览器的cookie中，当用户再次登录时，会获得对应的sessionid，然后将sessionid发送到服务端请求登录，服务端在内存中找到对应的sessionid，完成登录，如果找不到，返回登录页面。