我们什么时候打电话在同步方法和同步块之间使用

我们什么时候打电话使用同步方法和同步块。

如果要在方法调用期间锁定,并且要锁定 this (或当前类,用于 static 方法) synchronized 方法是正确的解决方案。

如果您正在锁定其他对象(例如私有锁对象或某些内部数据结构),那么同步块方法更好。

类似地,如果一个过程调用中只有一些代码需要在保持锁的情况下完成,那么最好使用一个同步块并 那个代码 在街区。

有性能问题吗?

没有,除了一般原则,持有锁的时间比你需要的时间长是个坏主意。(锁持有的时间越长,其他线程就越可能需要等待。)

我不知道你所说的“同步声明”是什么意思。您可以使用synchronized关键字来表示方法已同步,或者(如您所提到的)其中的代码块。

我通常倾向于保持方法小且易于管理,因此将整个方法标记为同步(如果需要)。这样做的好处是,类的用户可以立即发现哪些方法代表关键部分。它还允许您作为程序员更容易地确定类是否是线程安全的,即: 访问可变数据的所有公共方法是否都标记为已同步?

由于这两种方法都需要获取锁,因此它们之间没有性能差异。

如果可能的话,总是尝试使用synchronized块,对于任何不可能的情况,都可以使用synchronized方法。性能会有很大的提高,这取决于同步方法中的行数。随着生产线数量的增加,性能将下降。

当公共接口需要同步(c.f.同步集合)和同步块来进行类内部同步(例如访问需要线程安全的共享资源)时,我倾向于使用同步方法。

还有一个可读性问题。我发现方法级的同步更整洁、更明显,因为代码没有混乱的锁管理。

至于性能,我不知道这两种方法在行为上有什么特别的区别。我认为避免过度同步更重要,所以一个只需要访问共享资源1/10调用的方法应该使用块级而不是方法级同步。

我对任何给定场景的处理方法通常都是基于这些因素的混合,并根据以前的经验进行了修改。

就总体性能而言,同步块或方法之间没有区别。这个问题实际上是在编码实践方面。同步一个方法似乎是一件容易的事情,但是,当在一个项目中与多个人一起工作时,有人可能会改变一个简单的、轻量级的方法,而其他人同步到一个重量级的方法。事实上,一个很好的例子(从个人经验来看)是,当您使用依赖项注入框架,并且在服务对象中有与同步的数据访问对象(DAO)交互的方法时,您可能会遇到麻烦。预期DAO执行速度很快,因此只会短暂地持有锁。其他人来了,要么改变DAO,要么创建和注入新的DAO,这些DAO的速度要慢得多,而且由于服务对象与它进行了同步交互,所以突然事情开始变得非常慢。

我不认为同步块可以绕过我上面描述的那个问题,但是,至少对于同步块,它们比方法中的声明更难错过。