有人提到，对对象级锁使用显式锁声明(如下所示)是一种很好的做法。但是，我认为对于我们创建的对象的每个实例，我们最终都会为锁创建一个新对象并通过锁访问我们的方法，这都是昂贵的步骤。
但是，在同步方法的情况下，我相信不存在使用对象自己的锁的情况，您只需支付获取锁的成本。您可以避免创建显式锁定对象。
我在这里遗漏了什么吗？
public class DemoClass
{
private final Object lock = new Object();
public void demoMethod(){
synchronized (lock)
{
//other thread safe code
}
}
}
最佳答案
Is using explicit locks considered expensive?
一般来说，不会。它不被认为是昂贵的。 (模不同的人有不同的看法，不同的应用程序有不同的要求。)
锁 Object 实例的成本约为 8 个字节的内存加上保存对父对象中锁的引用的变量的内存。总共 12 或 16 个字节。
创建锁Object实例的成本是......几纳秒。 (不完全确定有多少，但这是微不足道的。)
当锁Object实例变成垃圾时，回收它的成本通常为零。 (当锁及其父对象不是垃圾时会产生GC成本...)
这些成本都是微不足道的，除非您有数百万个这样的对象或者对象周转率过高或者您有严重的内存或延迟限制。
(或者，如果您决定在不需要锁定的事物上放置/使用锁。但这是一个不同的问题。)
在显式锁定对象上获取或释放锁定与在 this 上获取/释放锁定的成本(据我所知)差异很小。也许是一次内存访问。
对于典型应用程序来说，这些成本差异并不重要。将会有更重要的事情需要优化。标准建议适用:
- 从简单的代码开始1。简单更容易编写、调试……和阅读。
- 避免过早优化；例如当你编写代码时。
- 在优化之前对您的应用程序进行基准测试和分析。
- 使用测量结果来决定哪些内容值得优化。
与锁定this可能导致的潜在问题相比，性能问题可能显得微不足道。实际上，这取决于您的应用程序复杂性和实现细节。
1 - 对于您和您的同事来说足够简单。它取决于上下文。
关于java - 使用显式锁是否被认为是昂贵的？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/59833183/