神州信息 Java开发面经（HR+技术双面）

面试题目

HR面

1. 自我介绍
2. 能否出差？
3. 意向薪资是多少？
4. 是否有其他 Offer？
5. 在实习经历和项目经历中学到了什么？

技术面

本轮全程八股，涉及 Redis 和 Java 基础，无项目深挖。

1. Redis 的不足之处是什么？不适合哪些业务场景？
2. 在银行场景中使用 Redis 这样的缓存数据库，有哪些应用场景？
3. 线程的几种实现方式？
4. Java 里的自动装箱和拆箱原理是什么？
5. final 和 finally 有什么区别？
6. Java 的基本数据类型有哪些？
7. 银行业务过程中会使用 double 这种双精度类型吗？
8. 用户密码能不能用明文存储？不用明文的话，你会用什么方式？
9. 发报文过程中用明文还是密文？用什么通讯协议？HTTPS 可以吗？

---

参考解析

1. Redis 的不足之处及不适合的场景

• 数据持久化弱：RDB/AOF 均存在数据丢失风险，不适合强一致性场景。
• 内存成本高：数据全量驻内存，不适合存储海量冷数据。
• 不支持复杂查询：无法替代关系型数据库做多表关联、复杂聚合。
• 不适合场景：金融核心账务系统、需要事务强一致的转账业务、大文件/二进制存储。

2. 银行场景中 Redis 的应用场景

• 会话缓存：存储用户登录 Token，支持快速鉴权。
• 热点数据缓存：缓存汇率、利率等高频读取的基础数据。
• 分布式锁：防止并发重复提交（如转账、下单）。
• 限流计数器：利用 INCR + 过期时间实现接口访问频率限制。
• 消息队列（轻量）：利用 List 或 Stream 做异步通知。

3. 线程的几种实现方式

• 继承 Thread 类：重写 run() 方法，单继承限制较大。
• 实现 Runnable 接口：更灵活，推荐方式，可配合线程池使用。
• 实现 Callable 接口 + FutureTask：支持返回值和异常抛出。
• 线程池（ExecutorService）：生产环境推荐，统一管理线程生命周期。

4. 自动装箱与拆箱原理

• 装箱：基本类型 → 包装类，编译器自动调用 Integer.valueOf(int)。
• 拆箱：包装类 → 基本类型，自动调用 intValue() 等方法。
• 缓存陷阱：Integer.valueOf() 对 -128~127 有缓存，== 比较此范围内值为 true，超出则为 false，应使用 equals()。
• NPE 风险：包装类为 null 时拆箱会抛出 NullPointerException。

5. final 与 finally 的区别

• final：关键字，修饰类（不可继承）、方法（不可重写）、变量（不可重新赋值）。
• finally：异常处理块，try-catch-finally 中无论是否发生异常都会执行，常用于资源释放。
• 两者无直接关联，属于完全不同的语言特性。

6. Java 基本数据类型

共 8 种：byte(1B)、short(2B)、int(4B)、long(8B)、float(4B)、double(8B)、char(2B)、boolean(1bit/JVM实现相关)。

7. 银行业务中能否使用 double？

• 不能用 double：浮点数存在精度丢失问题（如 0.1 + 0.2 ≠ 0.3），在金融计算中会导致金额误差。
• 正确做法：使用 BigDecimal，并通过字符串构造（new BigDecimal("0.1")）避免精度问题，运算时指定舍入模式（如 RoundingMode.HALF_UP）。

8. 密码存储方式

• 绝对不能明文存储，一旦数据库泄露用户密码直接暴露。
• 推荐方案：使用慢哈希算法 BCrypt 或 Argon2，内置盐值，防止彩虹表攻击。
• 不推荐：MD5/SHA1（已被破解，速度过快，易被暴力枚举）。
• 存储格式：hash(salt + password)，盐值随机生成并与哈希值一同存储。

9. 报文传输：明文/密文与通信协议

• 金融报文必须用密文：涉及账户、金额等敏感信息，需加密传输。
• HTTPS 可以用：基于 TLS/SSL，提供传输层加密，适合 Web 接口场景。
• 金融专线场景：往往额外在应用层对报文体进行加密（如 SM4 国密算法），即使 HTTPS 被中间人破解，报文内容仍受保护（双重加密）。
• 常见协议：HTTPS（REST）、SFTP（文件报文）、ISO 8583（银行卡报文专用协议）。