java中runnable接口的普通字段在多线程下不具备内存可见性，因jmm中线程工作内存与主内存分离，且存在重排序和jit优化；需用volatile、synchronized或atomic类显式保证。
Java中实现Runnable接口时，内部属性在多线程环境下默认**不具备内存可见性**。多个线程共享同一个Runnable实例对象时，对其中普通字段（如int i = 10、boolean flag = false）的读写操作，可能因JMM（Java内存模型）的工作内存与主内存分离机制，导致一个线程修改了值，另一个线程仍读到旧副本。
为什么普通字段会不可见
每个线程有自己的工作内存，读取共享变量时可能缓存其副本；写入时不强制刷回主内存。JVM还可能进行指令重排序或JIT热点优化（比如把while(flag)优化为先判断一次再死循环），进一步加剧不可见问题。
- 没有同步机制时，
i++这类操作也不是原子的：读取→修改→写入三步可能被其他线程穿插执行，造成竞态条件 -
flag被一个线程设为true，另一个线程的while循环可能永远不退出——因为它一直在读自己工作内存里的false - 即使加了
Thread.sleep()或人为延迟，也不能保证可见性，只是增加了“碰巧看到新值”的概率
如何让Runnable内部属性可见
必须显式引入内存屏障或同步语义，不能依赖代码顺序或sleep来“等待”刷新。
-
用
volatile修饰共享字段：适用于仅需保证可见性+禁止重排序的场景（如开关标志、状态标记）。例如：private volatile boolean running = true;。它不保证复合操作（如i++）的原子性 -
用
synchronized块或方法保护读写：进入同步块时会强制从主内存读最新值，退出时强制刷回。适合需要原子性+可见性的场景，如计数器累加 -
使用
java.util.concurrent.atomic包下的类：如AtomicInteger、AtomicBoolean，底层基于CAS和volatile，兼顾可见性与原子性
常见错误写法示例
以下写法看似合理，实则存在可见性漏洞：
- 在Runnable中定义
private int count = 0;，两个线程同时执行count++，最终结果大概率小于预期（如期望20，实际17） - 主线程启动子线程后，修改Runnable中的
stopRequested = true，但子线程while循环始终不退出——因为没加volatile或同步 - 认为
Thread.sleep(100)或System.out.println()能“触发刷新”，实际无任何JMM语义保障
正确做法建议
设计共享状态时，优先考虑是否真需多个线程共用同一个Runnable实例。更安全的做法是：
- 尽量避免在Runnable中维护可变共享状态；改用线程局部变量（
ThreadLocal）或参数传入不可变对象 - 若必须共享，明确标注哪些字段会被多线程访问，并统一用
volatile、final（初始化后不变）、或同步手段保护 - 调试时不要只看单次运行结果；可见性问题往往偶发，需多次运行或配合JVM参数（如
-server）复现
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
