-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: ZYL1210 <870138612@qq.com>
- Loading branch information
Showing
12 changed files
with
588 additions
and
466 deletions.
There are no files selected for viewing
This file was deleted.
Oops, something went wrong.
File renamed without changes.
File renamed without changes.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
--- | ||
title: 闲记 | ||
icon: xianji | ||
index: false | ||
cover: /home/202305122sdf05406.jpg | ||
pageInfo: false | ||
article: false | ||
timeline: false | ||
--- | ||
<div class="catalog-display-container"> | ||
<AutoCatalog /> | ||
</div> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
--- | ||
title: 面经 | ||
icon: interview | ||
index: false | ||
cover: /home/202305122sdf05406.jpg | ||
pageInfo: false | ||
article: false | ||
timeline: false | ||
--- | ||
<div class="catalog-display-container"> | ||
<AutoCatalog /> | ||
</div> |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,73 @@ | ||
--- | ||
title: 得物-Java开发-一二面 | ||
icon: duihua | ||
date: 2023-09-02 | ||
star: true | ||
category: | ||
- 面经 | ||
tag: | ||
- 得物 | ||
- 面经 | ||
--- | ||
|
||
⁉️ 个人回答不保证正确 | ||
|
||
## 一面 | ||
|
||
### 说一说 CMS 和 G1 垃圾收集器 | ||
|
||
- CMS 是标记清除算法的垃圾回收器,运行流程分为初始标记、并发标记、重新标记、并发清除,其中初始标记和重新标记会产生 STW,对在并发标记阶段修改的引用采用增量更新方法,G1 将堆内存分为多个 Region 区域,可以作为年轻代或者老年代,运行流程分为初始标记、并发标记、最终标记、筛选回收,其中除了并发标记阶段都会产生 STW,对并发标记阶段产生的引用链修改采用原始快照的方法。 | ||
|
||
### ReentrantLock 中的公平锁和非公平锁是怎么实现的? | ||
- ReentrantLock 基于 AQS 实现,其中有公平锁实现和非公平锁实现,对对象的加锁过程就是修改对象的 state 过程,采用 CAS 进行修改,修改失败表示有竞争,则会创建为一个 CLH 节点放入到 CLH队列的尾部,CLH 队列是一个虚拟的双向队列,其中存储了线程关系,存放在这个队列中的节点都是为竞争锁失败的节点。 | ||
- 公平锁实现:如果锁被释放,则会唤醒 CLH 队列中头节点的后一个节点,来竞争加锁,此时如果有一个新的线程也想进行加锁,则会检查 CLH 队列中头节点之后是否有节点,有节点则表示之前已经有线程等待了,则将自己放入 CLH 队列尾部。 | ||
- 非公平锁实现:在有新线程想加锁时,不管 CLH 队列中头节点之后是否有节点在等待,直接使用 CAS 尝试加锁。 | ||
|
||
### redo log 和 undo log 的作用? | ||
- redo log 用来记录数据库的修改,主要用来做崩溃恢复的,undo log 配合隐藏字段、Read View 实现 MVCC。 | ||
- **redo log 文件是啥样的?**(没太懂啥意思) | ||
- redo log 在磁盘中以日志文件组的形式出现,可以看成一个循环队列,包含 checkpoint 和 write pos,如果 write pos 追上 checkpoint ,表示日志文件组满了,这时候不能再写入新的 redo log 记录。 | ||
- **redo log 是顺序写吗?** | ||
- 是顺序写,如果对每次修改之后将一个页写回,可能只修改了很少的数据,没有必要这样做,并且页还不是顺序写效率较差,如果是 redo log 写,又是顺序写,整体效率较高。 | ||
|
||
### 两阶段提交了解吗? | ||
- 两阶段提交指的是 redo log 的提交分为两个阶段,分别是 prepare 和 commit,在 prepare 之后 binlog 写入,然后再 commit。 | ||
- 如果在 prepare 之后,出现问题,导致 binlog 写入失败,则发现没有对应的 binlog,事务将会回滚,如果是在写 binlog 之后发生错误,即使 redo log 没有 commit,但是有 binlog 则表明事务提交成功了,事务不会回滚。 | ||
|
||
### Spring 事务说说 | ||
- Spring 中事务通过 @Transactional 注解对方法提供事务支持,原理是创建一个动态代理对象,由动态代理对象执行这个方法,并对前后进行增强,也就是在执行数据库操作前将事务的提交模式改为手动,再进行数据库操作,发生异常则进行回滚。 | ||
|
||
### 什么情况下会产生事务失效? | ||
|
||
- 方法没有被 public 修饰,因为 CGLIB 动态代理是生成一个子类进行调用,如果父类方法不是 public 则调用不了。 | ||
- this 调用,需要使用动态代理对象调用方法才能让事务失效,this 调用是普通对象的调用。 | ||
- 异常没有正确抛出,如果内部将异常捕获了,外部 Spring 感知不到则会导致事务失效。 | ||
- 事务的传播机制设置错误,例如设置为 NEVER 则表示不使用事务。 | ||
- 数据库本身不支持事务。 | ||
|
||
### 什么情况下使用编程式事务什么情况下使用注解式事务? | ||
|
||
- (不太明白,我直接说没有用过编程式事务) | ||
- 编程式事务能在任何的代码片段中添加事物,而注解式事务的要求条件比较多,灵活性不如编程式事务。 | ||
- 注解式事务会导致方法开始的时候就申请连接,可能导致连接的利用率不高,不如编程式事务。 | ||
|
||
### SSL/TSL 了解吗? | ||
- (不了解)不太了解,只知道 HTTPS 是基于 SSL/TSL 实现的,这两个都是建立在 TCP 链接基础上的协议。 | ||
- HTTPS 为了防止中间人篡改信息,引入了证书机制,证书就是身份信息 + 公钥,将公钥发送给客户端,客户端通过上层证书提供商检查证书合法性,通过之后则会产生一个秘钥,秘钥通过公钥进行加密,到了服务器端通过私钥进行解密。服务器得到秘钥,之后的数据传输用这个秘钥进行对称加密。 | ||
- 总结就是发送的数据通过对称加密,加密使用的秘钥通过非对称加密。 | ||
|
||
### 国内输入谷歌网站但是访问不到,发生了什么? | ||
- 正常访问网页首先是通过域名 DNS 解析得到 IP 地址,查询方式有迭代查询和递归查询。之后与服务器建立 TCP 连接,然后发送请求到服务器,服务器返回数据,浏览器渲染。 | ||
- **访问不到 Google 的原因是在哪个环节?** | ||
- 我先说是 DNS,后来想了下回答是 TCP 连接环节。 | ||
- **防火墙在哪一个环节生效?** | ||
- TCP 连接环节,因为 TCP 是端到端的协议,需要提供端口,配置防火墙的时候需要添加入站和出站的端口。 | ||
|
||
### 反问 | ||
|
||
## 二面 | ||
|
||
### 学习中遇到困难如何解决的?请举例。 | ||
|
||
- 举了 float 浮点数的精度丢失问题,如何解决。线程安全问题,例如对 int 变量的并发修改问题,如何解决,volatile 关键字的实现原理,再延伸到 JVM 内存模型。 | ||
- 几乎没有太多技术性的问题。 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,100 @@ | ||
--- | ||
title: 富途-测试开发-一二面 | ||
icon: duihua | ||
star: true | ||
category: | ||
- 面经 | ||
tag: | ||
- 富途 | ||
- 面经 | ||
--- | ||
|
||
⁉️ 个人回答不保证正确 | ||
|
||
## 一面 | ||
|
||
### 自我介绍 | ||
|
||
### 谈谈你对测试流程的理解 | ||
|
||
- 最近才开始学测试,整体流程不是太了解,我认为是编写好文档,然后设计好输入的样例,查看输出结果是否能对应上。 | ||
|
||
### 为什么想投递测试? | ||
- 因为 Java 开发竞争太大了,而且会后端代码,能更好的做白盒测试。 | ||
- **其实竞争都挺大,哈哈。** | ||
|
||
### 对数据库的查询,数据进行排序获取前十个用什么关键字? | ||
- 使用 order by 和 limit。 | ||
- **如果进行分组呢?** | ||
- group by。 | ||
|
||
### 发现数据库查询的速度变慢,会想到什么优化措施? | ||
|
||
- 尽量减少 select * 的查询,如果数据库的数据太多,可以使用分库分表,经常查询的字段可以添加索引。 | ||
|
||
### 数据库死锁了解吗? | ||
|
||
- 操作系统中定义的死锁为有两个或者多个进程因为竞争资源导致阻塞,如果没有外力作用,两者都无法向前推进。 | ||
- 数据库中的死锁发生在两个事务对数据加锁并且请求修改对方加锁的数据。 | ||
- | ||
### 常见的 HTTP 状态码说下 | ||
|
||
- 200 请求成功,301 永久重定向,302 临时重定向,400 客户端错误,401 未授权,403 访问拒绝,404 页面没有找到,500 服务器错误,502 网关错误,504 网关超时。 | ||
|
||
### GET 和 POST 区别 | ||
|
||
- GET 用来请求数据,POST 用来插入数据。 | ||
- GET 幂等,POST 不幂等。 | ||
- GET 的参数放在 URL 中,POST 放在 Body 中。 | ||
- 这些都是规范,也可以不遵守,将后端的处理做好即可。 | ||
|
||
### TCP 和 UDP 的区别 | ||
|
||
- TCP 面向连接,字节流,可靠的传输层协议。 | ||
- UDP 不面向连接,不可靠的传输层协议。 | ||
- TCP 是端到端的协议,双方需要通过三次握手建立连接。 | ||
- UDP 可以产生广播消息,TCP 不可以。 | ||
- **UDP 适用于哪些场景?** | ||
- 视频对话,语音对话,对正确性要求不高的场景。 | ||
- TCP 适用于对要求高的场景,例如 FTP、POP3、SMTP、SSH 协议等都是基于 TCP 的。 | ||
- **那么我在腾讯视频看视频的时候应该用的是哪种传输协议?** | ||
- 应该是 TCP 吧,看视频其实就是文件传输的过程,使用 FTP 将文件传输到本地,然后通过播放器播放,对文件的完整性要求高。 | ||
|
||
### 如果有八个球,其中七个球的重量是相同的,另外一个球稍微重一点,给你一个天平,需要多少次比较能得到最重的球? | ||
|
||
- 刚开始想到的是二分查找,首先 4V4,然后 2V2,再 1V1。 | ||
- **不对,还可以做优化。** | ||
- 能给点提示吗? | ||
- **例如三个球,当中有一个重一点,则需要几次比较?** | ||
- 一次,选择两个球,如果当中有一个重,则就是目标球,如果两个重量相等剩下的就是目标球。 | ||
- 所以八个球的场景下,应该先 3V3,如果有一边重,则退化为三个球的场景,如果同样重,则最重的球在剩余两个球中,需要一次比较。 | ||
|
||
### 有一根绳子,从一边开始烧,烧完需要一个小时,则如何通过烧绳子计时 1 小时 15 分钟? | ||
- 首先用两根绳子,当中一个从两边开始烧,需要半个小时烧完,另外一个先从一边开始烧,到了半个小时之后将另外一边点燃,则再过 15 分钟烧完。 | ||
- 剩余一个小时再烧一根绳子即可。 | ||
|
||
### 代码题爬楼梯 | ||
|
||
- 动态规划 | ||
|
||
### 有 n 个人,他们各自有一个礼物,送给其他人,并且不能拿到自己的礼物,打印所有情况 | ||
|
||
- (回溯光速写完,以为秒了)。 | ||
- **有个 BUG 你发现了吗?例如有五个人,前四个只拿到了前四个人的礼物,则最后一个人只剩下自己的礼物怎么办?** | ||
- 跟前面任意一个人交换礼物即可。 | ||
|
||
### 代码题,找出无序数组中的最大值和最小值 | ||
|
||
- 线性查找 | ||
|
||
### 反问 | ||
|
||
## 二面 | ||
|
||
### HashMap底层结构 | ||
|
||
### 从 1 ~ N 的数字中随机取出 M 个 数字,时间复杂度要求为 M | ||
|
||
### 52 张扑克牌中,取出炸弹的概率大还是顺子的概率大? | ||
|
||
### 有 10 个袋子,每个袋子里面都有 100 个硬币,其中 9 个袋子中的硬币重量是相同的,都是 10 克,另外一个袋子里的硬币是 9 克,如果只用一次带刻度的电子秤,找到 9 克硬币的袋子的方法 |
Oops, something went wrong.