Implement more granular locks for a Singleton scope in Guice.

Now when you can create two independent singletons using
the same injector in different threads.
This make it easy to create scopes creating singletons using
thread pools with all the concurrency being done by Guice.
As a nice side effect Singleton scope is no longer treated
specially in Guice codebase.

The obvious problem to solve is potential deadlocks:
A requires B, B requires C, C requires A where all are
singletons and all are created simultaneously.
It's impossible to detect this deadlock using information
within one thread, so we have to have a shared storage.

An idea is to have a map of creators' locks and a map
of which threads are waiting for other singletons to be created.
Using this information circular dependencies are trivially
discovered within O(N) where N is a number of concurrent threads.

Important to not that no other deadlock scenarios within
Guice code is introduced as Guice does not expose any
other scopes that can span several threads.

Now it would be possible for
client code to deadlock on itself with two lazy singletons
calling each other's providers during creation.
This is deemed as a non-issue as it is up to the client
to write a thread-safe code.
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=91610630
19 files changed
tree: 604e25005690d696b2a7ee8ac39273aca98af3b4
  1. .gitattributes
  2. .gitignore
  3. .travis.yml
  4. CONTRIBUTING.md
  5. COPYING
  6. README.md
  7. bom/
  8. build.properties
  9. build.xml
  10. common.xml
  11. core/
  12. examples/
  13. extensions/
  14. jdk8-tests/
  15. latest-api-diffs/
  16. lib/
  17. pom.xml
  18. util/
README.md

Guice

Now, out in 4.0 Beta5!

Documentation: User Guide, 3.0 javadocs, Latest javadocs
Continuous Integration: Build Status
Mailing Lists: User Mailing List, Developer Mailing List
License: Apache 2.0

Put simply, Guice alleviates the need for factories and the use of new in your Java code. Think of Guice's @Inject as the new new. You will still need to write factories in some cases, but your code will not depend directly on them. Your code will be easier to change, unit test and reuse in other contexts.

Guice embraces Java's type safe nature, especially when it comes to features introduced in Java 5 such as generics and annotations. You might think of Guice as filling in missing features for core Java. Ideally, the language itself would provide most of the same features, but until such a language comes along, we have Guice.

Guice helps you design better APIs, and the Guice API itself sets a good example. Guice is not a kitchen sink. We justify each feature with at least three use cases. When in doubt, we leave it out. We build general functionality which enables you to extend Guice rather than adding every feature to the core framework.

Guice aims to make development and debugging easier and faster, not harder and slower. In that vein, Guice steers clear of surprises and magic. You should be able to understand code with or without tools, though tools can make things even easier. When errors do occur, Guice goes the extra mile to generate helpful messages.

For an introduction to Guice and a comparison to new and the factory pattern, see Bob Lee's video presentation. After that, check out our user's guide.

We've been running Guice in mission critical applications since 2006, and now you can, too. We hope you enjoy it as much as we do.

jolt award