Gson 性能是否受益于高度多线程应用程序中的资源池？
Does Gson performance benefit from a resource pool in highly multi-threaded applications?
我正在开发一个高度多线程的 Java 应用程序，其中单个全局 Gson 实例在大量线程之间共享。目前我没有注意到任何性能下降，但是到目前为止，正在处理的 Json 的数量相对较低。
我想知道创建每个线程获取和释放 Gson 实例的 Gson 实例资源池是否有意义 from/to？具体来说，是否可以避免线程阻塞等待访问全局Gson实例的情况？
Gson 文档提到：“Gson 实例是线程安全的，因此您可以跨多个线程自由地重用它们。”。但是，我无法弄清楚这是否意味着它只是锁定直到完成，或者它是否使用了一些内部资源池。
I was wondering if it would make sense to create a resource pool of Gson instances which every thread acquires and releases Gson instances from/to?
不，不会。
Gson thread-safety 是通过其不变性和 creator/factory-like 设计实现的。
Gson 实例一旦创建就无法更改，并且 Gson class 不提供任何更改方式：
- 它是不可变的，它的状态不能从外部改变（它不提供可以改变它的状态的方法+它的字段声明
final来表达这个意图）。
- 它也不允许传递地改变它的状态（比如，它不允许你通过 "get" 方法获得私有字段并从外部改变对象）。
因为在Gson实例中没有什么要修改的，它不需要read-only语义的同步机制：
- 您不需要为您通常不会使用的东西付费（
synchronized 有它的成本）。
- 它使设计和实现变得简单。
因此调用任何Gson方法都是thread-safe，但是从这些方法返回的对象可能缺少thread-safety（例如JsonReader/JsonWriter不是 thread-safe；JsonElement 及其子 class 可能是 thread-unsafe；等等）。
考虑到这一点，您必须确保您的类型适配器 (Gson serializers/deserializers) 在设计上是 thread-safe，并且不会更改其内部状态——Gson 严重依赖于此（据我所知，所有 Gson built-in 类型的适配器都是不可变的）。
显然，如果特定类型的适配器使用同步机制（这显然是一个瓶颈），Gson from 和 to 方法可能会等待，如果它们使用这种类型的适配器，但你仍然能够使用来自其他线程的 Gson 实例（但是我永远不会设计、实现和使用在幕后使用同步的类型适配器）。
所以，
a single global Gson instance is shared between a large number of threads
完全没问题。
我正在开发一个高度多线程的 Java 应用程序，其中单个全局 Gson 实例在大量线程之间共享。目前我没有注意到任何性能下降，但是到目前为止，正在处理的 Json 的数量相对较低。
我想知道创建每个线程获取和释放 Gson 实例的 Gson 实例资源池是否有意义 from/to？具体来说，是否可以避免线程阻塞等待访问全局Gson实例的情况？
Gson 文档提到：“Gson 实例是线程安全的，因此您可以跨多个线程自由地重用它们。”。但是，我无法弄清楚这是否意味着它只是锁定直到完成，或者它是否使用了一些内部资源池。
I was wondering if it would make sense to create a resource pool of Gson instances which every thread acquires and releases Gson instances from/to?
不，不会。
Gson thread-safety 是通过其不变性和 creator/factory-like 设计实现的。
Gson 实例一旦创建就无法更改，并且 Gson class 不提供任何更改方式：
- 它是不可变的，它的状态不能从外部改变（它不提供可以改变它的状态的方法+它的字段声明
final来表达这个意图）。 - 它也不允许传递地改变它的状态（比如，它不允许你通过 "get" 方法获得私有字段并从外部改变对象）。
因为在Gson实例中没有什么要修改的，它不需要read-only语义的同步机制：
- 您不需要为您通常不会使用的东西付费（
synchronized有它的成本）。 - 它使设计和实现变得简单。
因此调用任何Gson方法都是thread-safe，但是从这些方法返回的对象可能缺少thread-safety（例如JsonReader/JsonWriter不是 thread-safe；JsonElement 及其子 class 可能是 thread-unsafe；等等）。
考虑到这一点，您必须确保您的类型适配器 (Gson serializers/deserializers) 在设计上是 thread-safe，并且不会更改其内部状态——Gson 严重依赖于此（据我所知，所有 Gson built-in 类型的适配器都是不可变的）。
显然，如果特定类型的适配器使用同步机制（这显然是一个瓶颈），Gson from 和 to 方法可能会等待，如果它们使用这种类型的适配器，但你仍然能够使用来自其他线程的 Gson 实例（但是我永远不会设计、实现和使用在幕后使用同步的类型适配器）。
所以，
a single global Gson instance is shared between a large number of threads
完全没问题。