继续帮公司面试2万的java程序员，一轮电话面试很基础

面试视频版本在 B站，欢迎大家观看

B站（哔哩哔哩）：我是程序汪，今日头条：程序汪

视频可能更有感觉哦

面试的答案在本文章

建议大家先看视频，然后看自己能否回答上

回答不上的回头看看本文章效果更好哦

面试的日子里有程序汪的面试视频和文章，面试不慌了（这广告打的）

这也算模拟面试吧，谢谢大家支持，

程序汪出了很多面试视频了，自我介绍的经验也分享了很多版本，这次站在面试官角度在唠叨下，面试官希望听什么的介绍

学历年龄工作经验这样硬指标简历首页上已经说清楚了，介绍简单说明就可以了，比如你年龄都不写简历上，面试官肯定知道你隐瞒的意图。

• 如果你跳槽特别频繁，建议里把跳槽原因说明下，如公司倒闭、业务萎缩等客观不可抗原因，很多HR看到跳槽频繁的简历直接就不给面试机会了(残酷的现状)。
  
• 项目描述一定要详细清楚，业务背景、技术特点、自己负责模块，面试官对简历最感兴趣的就是项目描述了，面试官一般都是先找项目中和公司里技术匹配度高的点去发问，比如 美团外卖就是 微服务高并发的技术特点，面试官肯定也对项目中有这些特点的项目描述感兴趣。
• 要自信的表达，很多面试者怕这怕那，真没必要，自信的把自己项目描述清楚，业务上、后端DB设计、异常设计、设计模式、技术亮点、技术缺点也可以说，反正让面试官感觉出你是一个有想法的面试者。
  
  

这类面试题回答其实比较简单，但回答很全面就有点困难了

运行速度快慢为：StringBuilder > StringBuffer > String  

在线程安全上，StringBuilder是线程不安全的，而StringBuffer是线程安全的

适用场景

String：少量的字符串操作的场景

StringBuilder：单线程下在字符缓冲区进行大量操作的场景

StringBuffer：多线程下在字符缓冲区进行大量操作的场景

虽然jdk14快出来了，其实主流的jdk1.8很多人都没玩熟练，甚至有些老爷项目还是jdk1.6,如果你进的公司项目全部都是1.6，我感觉还是早点换个地方学技术吧，除银行保险这些企业（太安逸，一杯茶一包烟一个参数传一天）程序汪以前去过某银行公司上班，不过是外派过去的，进去前3个月一行代码没写，光写设计文档，安逸的不想走啊。跑题了

jdk1.8新特性知识点：

• Lambda表达式

• 函数式接口

• *方法引用和构造器调用

• Stream API

• 接口中的默认方法和静态方法

• 新时间日期API

程序汪主要说下Lambda表达式，快速开发业务代码利器，但不要过度使用，

特别复杂的建议还是原生态吧

本质上是一段匿名内部类，可以传递代码

强烈推荐大家看下

提高开发效率和优雅度，java8流式语法，真的可以有

程序汪发现Lambda最通俗易懂的一篇文章(收藏表示你看了)

java8函数式Map操作也太强大了吧，1次就帮我省了10多行代码

很多程序员没在实战中写过排序的代码，程序汪一问，很多人回答我SQL排序，面试官就想听听你对java中排序API的熟悉度

如果面试者能回答到这些就很好

• Arrays.sort()和Collections.sort()

• 使用Comparable接口   Comparable接口定义了compareTo方法，用于对象之间的比较

• 使用Comparator接口  Comparator可以用于比较没有实现Comparable的类的对象

这类面试题回答其实比较简单，为什么单例 

单例：Spring容器中某一个类只有一个实例，而且自行实例化后并项整个系统提供这个实例，这个类称为单例类

• 线程安全  :单例缺点很明显线程不安全，因为多个线程共享这个实例，所以多线程场景需要考虑这个问题

• 资源复用：减少创建类的资源开销，创建对象多了占内存又耗性能，spring一般是通过反射技术实例对象的， 影响jvm垃圾回收，对象少了自然回收快了

简单总结下

1.少创建实例

2.垃圾回收

3.缓存快速获取

如果是有状态的话在并发环境下线程不安全

有状态举个例子比如单例是全国城市对象，2个线程同时操作一个线程删除了上海对象就会导致另一个线程操作上海失败

程序汪面试的时候发现很多面试者一个通病，多线程都不知道什么场景下用

于是程序汪把自己项目中多线程场景整理2个常见业务场景

案例一 大数据量查询【查】

很多场景PD就是要一次性加载所有数据不能分页，如程序汪就开发一个需求 广告数据加载由于一次加载1万多数据 后端耗时比较大，后来优化方案是 通过5个线程 每个线程加载2千数据 这样DB耗时大大减少了，这里请注意线程设置的数量不能太多也不能太少。

代码思路

1. 拆分大数据（分页思想），1万多条数据根据合理数量拆分， 推荐拆分集合代码 com.google.common.collect.Lists.partition(list,2000),亲们不要自己傻傻的写工具类哦，bug多不说关键是丑，这个2000是程序汪测试验证出来的，也试了5次左右

2. org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor利用spring的线程池

3. 使用java中Callable来接受返回数据

案例二，批量更新请求【更新】

上游系统需要调用下游系统批量创建广告数据，因为需要及时的响应返回前端页面， 这对性能是有要求的，肯定不能简单的轮询遍历去调用下游创建广告数据了，必须并发调用。

当时有2个方案

1.下游系统并发创建广告数据，上游系统透传一个集合过来就行，下游接口提供批量创建的接口

2.上游系统并发调用下游系统去创建，下游提供单个广告创建接口就可以

这2个方案最后程序汪公司选择了第2个方案，原因是下游系统批量并发操作是在单台机器上处理的，公司的集群就浪费掉了，目前下游是10多台机器的，上游并发就可以均匀的打在10台机器上处理，当然并发线程数必须合理设置，如果并发太大会导致下游DB连接池数量耗尽 抛出异常。

关键字总结

• 并发
  

• 负载均衡

• 线程池数量

• DB连接池数量
  

上面程序汪提供了些具体案例和并发需要考虑的问题，请大家不要滥用并发，上生产前一定要压测下，考虑机器资源DB资源等等是否充分利用

springboot上搭建个多线程小demo,送给学习的你

已经有很多粉丝让我举例具体生产问题，我就列举几个公司生产问题案例给大家参考下，敏感信息脱敏下 主要列举问题

• mybatis并发线程不安全问题，解决 升级mybatis版本

• 利用线程池开发业务功能，但对多线程的无序性考虑不足，导致业务数据更新顺序出现问题（数据不一致了），解决方案 加上 同步标识ID,代码上判断 同步标识存在了标识处理过了

• 折扣字段精度 使用double进行计算（还在用double表示钱相关的程序员绩效工资可以扣光了），精度缺失 改成BigDecimal

• NPE(空指针)，业务场景考虑不足，特定场景数据空了，但代码没考虑防空，这个问题非常低级但是出现频率最高，生产环境数据本来就很复杂，小开发经常考虑不足

• 超时导致双方数据不一致，生产环境偶尔会出现超时情况，解决方案 人工数据订正，通过核对系统及时发现数据不一致问题

生产问题导致

• 环境问题，如软件版本兼容等等问题

• 代码问题，基础知识差，经典案例钱用double表示
  

• 沟通问题，理解需求偏差，缺少思考缺少沟通

• 测试问题，测试验证考虑不足

• 框架本身问题，如FastJSON出现远程利用漏洞

这是程序汪发现生产问题跟踪表格，大家可以借鉴下

金钱要使用BigDecimal数据类型(使用double的已经被公司开除了)