完成其他回答:

只有当方法中的代码做以下两件事之一时，同步才会令人担忧:

使用一些非线程安全的外部资源。 读取或更改持久对象或类字段

这意味着在方法中定义的变量总是线程安全的。对方法的每次调用都有自己版本的这些变量。如果方法是由另一个线程调用的，或者是由同一线程调用的，甚至是方法调用自身(递归)，这些变量的值是不共享的。

线程调度不保证是循环的。一个任务可能会以牺牲相同优先级的线程为代价完全占用CPU。你可以使用Thread.yield()来获得良心。你可以使用(java) thread . setpriority (thread . norm_priority -1)来降低线程的优先级

另外还要注意:

迭代这些“线程安全”结构的应用程序的巨大运行时成本(已经被其他人提到)。 Thread.sleep(5000)应该休眠5秒。但是，如果有人更改了系统时间，您可能会睡很长时间或根本没有时间。操作系统记录唤醒时间是绝对的，而不是相对的。

与其认为代码或类是线程安全的，我认为将操作视为线程安全的更有帮助。如果两个操作在从任意线程上下文运行时按照指定的方式运行，那么它们就是线程安全的。在许多情况下，类将以线程安全的方式支持一些操作组合，而其他则不支持。

例如，许多像数组列表和散列集这样的集合可以保证，如果它们最初只由一个线程访问，并且在引用对任何其他线程可见后永远不会被修改，那么它们可以被任何线程组合以任意方式读取而不受干扰。

More interestingly, some hash-set collections such as the original non-generic one in .NET, may offer a guarantee that as long as no item is ever removed, and provided that only one thread ever writes to them, any thread that tries to read the collection will behave as though accessing a collection where updates might be delayed and occur in arbitrary order, but which will otherwise behave normally. If thread #1 adds X and then Y, and thread #2 looks for and sees Y and then X, it would be possible for thread #2 to see that Y exists but X doesn't; whether or not such behavior is "thread-safe" would depend upon whether thread #2 is prepared to deal with that possibility.

As a final note, some classes--especially blocking communications libraries--may have a "close" or "Dispose" method which is thread-safe with respect to all other methods, but no other methods that are thread-safe with respect to each other. If a thread performs a blocking read request and a user of the program clicks "cancel", there would be no way for a close request to be issued by the thread that's attempting to perform the read. The close/dispose request, however, may asynchronously set a flag which will cause the read request to be canceled as soon as possible. Once close is performed on any thread, the object would become useless, and all attempts at future actions would fail immediately, but being able to asynchronously terminate any attempted I/O operations is better than require that the close request be synchronized with the read (since if the read blocks forever, the synchronization request would be likewise blocked).

线程安全代码按照指定的方式工作，即使由不同的线程同时输入。这通常意味着，应该不间断地运行的内部数据结构或操作受到保护，不会同时进行不同的修改。

是也不是。

线程安全不仅仅是确保共享数据一次只能被一个线程访问。您必须确保对共享数据的顺序访问，同时避免竞争条件、死锁、活动锁和资源短缺。

当多个线程同时运行时，不可预知的结果并不是线程安全代码的必要条件，但这通常是一种副产品。例如，您可以使用一个共享队列、一个生产者线程和几个消费者线程来设置生产者-消费者方案，并且数据流可能完全可预测。如果你开始引入更多的消费者，你会看到更多随机的结果。

从本质上讲，在多线程环境中，许多事情都可能出错(指令重新排序，部分构造的对象，由于CPU级别的缓存，相同的变量在不同的线程中具有不同的值等)。

我喜欢Java并发实践中给出的定义:

如果一个[部分代码]在从多个线程访问时行为正确，那么它就是线程安全的，而不考虑运行时环境对这些线程的调度或交错执行，并且在调用代码方面没有额外的同步或其他协调。

正确的意思是程序的行为符合它的规范。

的例子

假设您实现了一个计数器。你可以说它的行为是正确的，如果:

Counter.next()从不返回之前已经返回过的值(为了简单起见，我们假设没有溢出等) 从0到当前值的所有值都已在某个阶段返回(没有跳过任何值)

线程安全计数器将根据这些规则进行操作，而不管并发有多少线程访问它(通常不是简单实现的情况)。

注意:交叉贴在程序员上

用最简单的话来说:P 如果在一个代码块上执行多个线程是安全的，那么它就是线程安全的*

*适用条件

条件被其他的答案提到，比如 1. 如果你执行一个线程或多个线程，结果应该是相同的。