神州信息 Java开发面经（HR+技术双面）
面试题目
HR面
- 自我介绍
- 能否出差？
- 意向薪资是多少？
- 是否有其他 Offer？
- 在实习经历和项目经历中学到了什么？
技术面
本轮全程八股，涉及 Redis 和 Java 基础，无项目深挖。
- Redis 的不足之处是什么？不适合哪些业务场景？
- 在银行场景中使用 Redis 这样的缓存数据库，有哪些应用场景？
- 线程的几种实现方式？
- Java 里的自动装箱和拆箱原理是什么？
final和finally有什么区别？- Java 的基本数据类型有哪些？
- 银行业务过程中会使用
double这种双精度类型吗？ - 用户密码能不能用明文存储？不用明文的话，你会用什么方式？
- 发报文过程中用明文还是密文？用什么通讯协议？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（银行卡报文专用协议）。