atm类设计需保证线程安全：账户余额用atomicinteger或synchronized保护；account与atm解耦；余额操作返回boolean；避免在getter/tostring中做业务判断；withdraw需严格参数校验。
ATM类怎么设计才不崩在多线程场景
Java里写ATM模拟，很多人第一反应是把所有逻辑塞进一个ATM类，账户余额用int或double存——这在单次运行测试时没问题，但只要加个循环调用或模拟并发取款，立刻出现负余额、重复扣款、余额对不上。根本原因是没隔离状态变更的原子性。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 账户余额必须用
AtomicInteger或synchronized块保护，别信“我只测一次不会出错” -
Account类要独立，和ATM解耦；ATM只负责流程控制，不直接操作balance字段 - 所有涉及余额变更的操作（取款、存款）必须返回
boolean表示是否成功，而不是void——失败时调用方才知道该提示“余额不足”还是重试 - 避免在
toString()或getter里做业务判断，比如getBalance() > 0 ? "正常" : "冻结"，这会让封装失效
取款方法withdraw()的参数校验不能只靠if (amount
表面看这个判断够了，但实际运行中会遇到：用户输-100、输100.5、输abc转成0、甚至传入null（如果用了Integer包装类）。Java没运行时类型检查，这些全靠你堵在入口。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 参数类型强制用
int而非Integer，避免NullPointerException - 在
withdraw(int amount)开头立刻检查：if (amount - 再查是否超限：
if (amount > this.balance.get()) return false;（注意用get()而非直接读字段） - 别在Service层做输入解析——比如把字符串"500"转成int的工作，应该在UI或main方法里做完，
withdraw()只接收干净整数
为什么不用Scanner.nextLine()直接读卡号和密码
新手常把Scanner当万能输入工具，但在ATM流程中，卡号要校验长度、密码要隐藏显示、连续输错三次得锁卡——这些都不是nextLine()能解决的。更麻烦的是，它不处理输入流残留，比如先读int再读String，nextLine()会直接返回空行。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 卡号用
long或String存（推荐String，方便校验长度和前缀），别用int——12位卡号早超int范围 - 密码绝不存明文，哪怕模拟系统也得用
char[]接收，用完立刻Arrays.fill(pwd, '\u0000')清空 - 输错三次锁定，得在
Account类里加int failedAttempts和boolean locked字段，且每次验证后更新 - 别在
while(true)里反复new Scanner(System.in)，复用同一个实例
main方法里new ATM().run()为什么总卡死或跳过输入
典型现象：程序启动后直接打印“欢迎使用”，然后退出；或者输入卡号后不等密码就报错No line found。问题往往出在输入流被提前消费，或异常没捕获导致进程静默终止。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- main里必须包
try-catch (Exception e)，至少System.err.println(e.getMessage())，否则InputMismatchException这种错你看不见 - 别用
scanner.nextInt()读菜单选项后紧跟nextLine()——前者不吞回车，后者立刻读到空行；统一用nextLine()再Integer.parseInt() -
ATM.run()里用while (!exitFlag)，别写while (true)加break，exitFlag要声明为volatile（哪怕单线程也养成习惯） - 退出前调用
scanner.close()，否则IDE可能报资源泄漏警告
真正难的不是写完功能，是让每笔取款都可验证、每次输错都有反馈、每个对象生命周期清晰可控。很多所谓“封装练习”，最后变成一堆public字段+public方法，那只是把C代码换行写了而已。
