search

dungnn / google-gson

Automatically exported from code.google.com/p/google-gson
0 stars 0 forks source link

Gson.getAdapter(Type) has low concurrency #437

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Run Gson.toJson in a highly concurrent environment
2.
3.

What is the expected output? What do you see instead?

Less thead blocking

What version of the product are you using? On what operating system?

Gson 2.1 on Mac OS X 10.7.3

Please provide any additional information below.

The first line of the implementation hits a synchronized map; In highly 
concurrent use cases this causes a significant amount of blockage (51% in my 
use case). As I am in a situation where creating large numbers of gson 
instances to work around this issue is not possible (i.e. - I have to use a 
shard Gson instance) I have a serious performance bottleneck.

I normally would provide a patch for this, but there are two distinct 
approaches that can equally solve this bug: Use a thread local for the cache, 
or use a concurrent collection. I generally favor thread locals, but this has 
the down side of causing the cache to be less effective as other threads can 
not cross pollinate the cache. However, concurrent maps (e.g.- 
ConcurrentHashMap) do not allow null keys; without the tribal knowledge of the 
implementation I could not utilize this collection without fear of breaking an 
existing use case.

Original issue reported on code.google.com by dirkharr...@gmail.com on 20 Apr 2012 at 2:31

GoogleCodeExporter commented 9 years ago 
Avoid this problem by using the TypeAdapter directly. That way Gson doesn't 
need to keep on looking up the type to serialize. This approach is also faster 
even if there isn't contention.

  public static final TypeAdapter<Foo> myFooAdapter = gson.getAdapter(Foo.class);

inder, joel: do you guys think we should encourage this?

Original comment by limpbizkit on 30 Jun 2012 at 3:26

GoogleCodeExporter commented 9 years ago 
I apologize for my naivety in advance.

This issue is occurring as a natural use of toJson(...). How would your 
suggestion resolve this (e.g. - I don't understand the equivalent API call of 
gson.toJson(...) using a specific TypeAdapter)?

Original comment by dirkharr...@gmail.com on 30 Jun 2012 at 12:38

GoogleCodeExporter commented 9 years ago 
We are running into this same issue. Using the TypeAdapter directly is not a 
viable option for us because some of type information in our serialized objects 
is dynamic. It seems like a simple change, and like the original author we 
could potentially provide a patch. Is there a fundamental objection to making 
this change, perhaps a concern about performance in low concurrency 
environments, or is it just a matter of resources?

Original comment by douglas....@gmail.com on 9 Jul 2013 at 1:30