在上一篇文章中，我们对作为函数闭包实现的装饰器与前文描述的通用装饰器进行了性能比较。本节我们继续我们的性能测试，看看装饰一个类方法时，不同实现方式的性能表现。

前面我们探讨了装饰器的实现方式，并实现了一个所谓的通用装饰器模式，并用它创建了一个类似 Java 的 @synchronized 装饰器作为使用示例。本节我们来看看不同的装饰器实现方式的性能问题。在这篇关于装饰器的实现性能这篇文章之后，我们将开始深入探讨如何实现代理，它是通用装饰器机制中的基础组件。

在前一篇文章中，我们描述了如何使用新的通用装饰器模式来实现Python的 @synchronized 同步原语装饰器。在Java提供的两个同步机制中，同步方法和同步原语，目前为止我们只实现了同步方法。本文将描述如何将其扩展为上下文管理器，从而等效的实现Java的同步原语。

在之前的博客中，我们讨论了装饰器的实现，并实现了一个通用装饰器模式。作为这种模式的使用示例，本节我们来实现 java 中的 @synchronized 装饰器。

1. Java @synchronized 装饰器

java 的同步原语有两种形式，分别是同步方法和同步代码块。在Java 中创建同步方法，只需要在其定义时添加synchronized关键字即可。

上一篇文章中，我们讨论了如何实现一个带参数的装饰器，以及如何让装饰器可选的接收参数而不是必需输入参数。也讨论了如何让装饰器能在被包装函数的不同调用之间保持状态。保持状态的一种可用方法是使用类实现装饰器。然而我们实现的通用装饰器模式在使用类实现装饰器还存在一些问题，本文我们将来探讨问题出现的根源以及如何解决。

在之前的博客，通过使用代理对象，装饰器工厂函数等技术，我们已经实现了一个通用装饰器。在这篇文章中，我们将使用前面文章中描述的装饰器工厂函数，介绍如何使用它来实现接受参数的装饰器，包括强制参数和可选的接收参数。