一个线程对long类型变量进行修改，多个线程只读这个long类型值，需要加锁吗？

232375

如果多个线程共享数据并不严格，高位又比较稳定，可以不用。time仅仅是显示而已。

lfwalkman

不要加锁，因为所有平台上32位值的读写都是原子的。
在写的过程中，不可能被读。
在读的过程中，不可能备写。

跟进一步，即使两个线程都要读写，如果写前后的数据没有依赖关系，也是不需要加锁的。但是要弄成volatile.
平时我们在++，--的时候需要加锁，是因为这里包含有一读，一写。而且写入的值，需要依赖写前读到的值。
就是典型的“read->execute->store"模式，这个时候需加锁。

lfwalkman

如果平台上对32值的存取是原子的，就不要加锁，
但是有些平台不保证这个，就要加锁。不然写一半就读了。

todaygood

long 在32位机上是32位，在64位机上是64位，也就是一个字。

按微机原理，读取一个字，一条指令就可以了，因此是原子的。
现在的问题是，一个线程写，一个线程读， 要不要加锁？理论上线程是CPU调度的最小单位
我认为：如果是单核的CPU，某个时刻只存在一个操作指令，要么读，要么写，所以是不需要加锁的。
            如果是多核的CPU,  某个时刻就可能同时运行多个指令，多个指令去访问同一个内存区是需要加锁的，
        但楼主提出的问题是一个线程读，一个线程写这个场景，即使你加锁了， 也没啥用处，哪一条指令谁先谁后是无法保证的，锁只能保证同一时刻只有一个线程进行访问。
      
      锁并不能解决顺序性的问题，多线程的程序本来就有顺序不定性的特点。所以本贴讨论好像有点偏了，偷换了概念： 要不要用加锁的方法来解决多线程的不确定性。
      
       但事实是： 用锁根本就不能解决顺序性的问题，而不是用于不用的问题。

        如果要保证楼主程序中输出的确定性，一开始就不该考虑使用多线程；一旦你使用了多线程，就必然是不确定的。即使用锁也无法保证。