很多人在写多线程程序时都会遇到一个问题：我的数据被多个线程同时访问，会不会出问题？于是自然想到——线程安全是不是一定要加锁？其实这个问题没有绝对的答案，得看具体情况。
什么情况下需要加锁
当你有多个线程在读写同一个共享变量，并且这个操作不是原子的，那就很可能出问题。比如两个线程同时对一个全局计数器执行 i++，表面上看是一行代码，实际上包含了读取、加1、写回三个步骤。如果没加保护，两个线程可能同时读到相同的值，导致结果少算一次。
这时候，加锁就是一种常见的解决办法。用互斥锁（mutex）把临界区保护起来，确保同一时间只有一个线程能进入：
#include <pthread.h>
int counter = 0;
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
void* increment(void* arg) {
for (int i = 0; i < 100000; i++) {
pthread_mutex_lock(&lock);
counter++;
pthread_mutex_unlock(&lock);
}
return NULL;
}这样就能保证 counter 的值最终是准确的。就像超市里的试衣间，一次只能进一个人，其他人得排队等，这就是锁的作用。
不加锁也能线程安全的情况
并不是所有场景都非得加锁。有些情况本身就安全，比如多个线程只读不写，那根本不需要锁。就像图书馆里大家同时看同一本书的复印件，没人涂改，自然不会乱。
还有一种是用了原子操作。现代编程语言和硬件支持一些原子指令，比如 C++ 的 std::atomic，Java 的 AtomicInteger，这些类型的操作本身就是线程安全的，底层通过 CPU 指令保证不会被打断，不需要你手动加锁。
#include <atomic>
std::atomic<int> counter(0);
void* increment_atomic(void* arg) {
for (int i = 0; i < 100000; i++) {
counter.fetch_add(1);
}
return NULL;
}这种方式比加锁更轻量，适合简单的共享变量更新。
还有些工具本身是线程安全的
比如 Java 里的 ConcurrentHashMap，内部做了分段锁或 CAS 操作，你不用额外加锁也能安全使用。就像快递柜每个格子独立，不同人存取自己的包裹互不影响。
反过来，像 ArrayList 这种非同步容器，多个线程随便改就会出问题，这时候要么自己加锁，要么用 Collections.synchronizedList 包装一下。
加锁也不是万能的
锁用不好反而会带来新问题。比如死锁——两个线程互相等着对方释放锁；或者性能下降，本来想并行处理，结果全都堵在锁门口排队。
所以有时候会用无锁编程（lock-free），靠原子操作和内存序控制来实现并发安全，虽然写起来复杂，但在高并发场景下效率更高。
线程安全的核心是“正确性”，至于是否加锁，只是实现手段之一。关键看你用的数据结构、操作类型和并发模型。别一上来就想着加锁，先看看有没有更合适的办法。