Tools to assist with safe and performant concurrent java development

View the Project on GitHub threadly/threadly

Latest stable binary:
threadly-5.27.jar

A library of java tools to assist with development of concurrent java applications. This is designed to be a complement to java.util.concurrent and uses java.util.concurrent to help assist in it's implementations where it makes sense.

These tools provide things ranging from the KeyDistributedExecutor which allows for threading to be controlled, and portions of the application to be written in a single threaded context. To the unique priority based, high performance, thread pool. To the ability to create a hierarchy of thready pools (sub pools in threadly named "Limiters"). To the ability to control threading and allow things to easily run single threaded where it makes sense. This library also includes utilities for making it easier to unit test concurrent applications. As well as utilities to help debug concurrent designs.

To get a more complete overview of our features take a look at our features wiki page.

News:

* July 3rd - 5.27 was released which includes minor changes to further the improvement introduced in 5.26.

* July 1st - 5.26 was released, providing minor internal performance improvements to PriorityScheduler, and heap improvements when adapting DoNothingRunnable's into Callable's.

* June 19th - 5.25 was released. This contains a number of internal improvements and external improvements. Read about them in the release details.

* May 25th - 5.23 was released. Threadly has been getting a lot of attention lately. This release does include a small bug fix for the Profiler when used with the `SameThreadSubmitterExecutor`. However this release is focused mostly around improvements, performance improvements with futures and other minor improvements.

* May 21st - 5.22 was released as a follow up to the bug fix in 5.21. Not a recent regression, just another case of the defect that was missed.

* May 20th - 5.21 was released, focused around another bug fix around canceling collections of Futures produced by FutureUtils. We also now are using buildkite to perform our CI solution. Having talked with them I am pretty confident this will be a better fit for our needs.

* May 18th - 5.20 was released which includes important bug fixes for communicating the "canceled" state after a map / flatMap operation on a future. It also includes internal performance improvements and minor features expansions (which can be read about in the changelog).

* May 15th - Following closely behind 5.18, 5.19 provides internal improvements as well as minor features that can be read about in the changelog.

* May 4th - A feature expansion release of 5.18 was published to maven central today. The primary feature in this release is the add of `mapFailure` and `flatMapFailure` to `ListenableFuture`. These functions allow you to async transform futures from the error conditions back into results or into different error conditions.

* April 20th - 5.16 was released today. I had planned for 5.16 to be a feature expansion release. I have been working on a new sub-pool that will help threadly's central pool. However it's not ready yet. Instead this release contains a bug fix for the central pool where `isolatedTask` recurring tasks could decrement the central pools size after every run, eventually resulting in logging exceptions as the pool tries to shrink itself below zero. This critical bug fix pushed the release forward. But I am also excited to announce a new feature in FutureUtils. Now in addition to `scheduleWhile` there is `executeWhile`. This is more flexible to other pool types (as it does not even require a pool, just a `ListenableFuture`). It is conceptually the same, except where a delay for retry is not desired.

* March 6th - 5.15 was released today with new features, improvements, and some small bug fixes. All the details can be found in the Release notes.

* February 16th - 5.14 minor release with new StringUtils functionality and javadoc improvements.

* February 4th - 5.13 incremental improvements release. Release notes contain all the details, but this includes a variety of small incremental improvements. Typically not enough to warrant a release, with 5.X we plan to have more small releases like this.

* January 22nd - 5.12 bug fix release for unlikely, but possible, race condition when using the new ListenableFuture listener execution optimizations introduced in 5.10.

* January 17th - 5.11 release to provide pre-5.10 functionality when mapping ListenableFutures as `throwMap`. It was discovered that there is good reason to sometimes have the mapper function throw an exception, and that those should not be treated as "uncaught" exceptions. The default behavior of `map` will still report the exception to `ExceptionUtils.handleException`, since that is the behavior most people probably expect. But `throwMap` was added to facilitate the rare use case where you want / expect an exception to be thrown.

* January 16th - 5.10 release to include more minor bug fixes, as well as the opportunity to further optimize listeners being executed on `ListenableFuture`'s. Read more in the ListenableFuture.ListenerOptimizationStrategy javadocs.

* January 5th - Patch release to fix very old bug in `StripedLock`.

* December 28th - Released some new minor features in threadly version 5.8.

* December 19th - Released version 5.7. This is a fairly significant feature expansion release. Allowing limiters to not be impacted by the listener (monads) execution if desired. As well as the newly added `CentralThreadlyPool`. Allowing the limiters to not limit listeners / map functions allows you to be sure you are limiting a core task functionality, and not also including limits towards operations which may occur after that core task completes. The `CentralThreadlyPool` allows you to gain access to a scheduler / executor for the immediate needs, without having to worry about a scheduler life cycle (ie shutting down). Internally this pool will try to reduce thread churn as much as possible while also making sure that the threads are available for the task demand requested (and not letting any single scheduler fully take control over the pool). This feature has been one in the works for a while, and I am pretty happy with how it came out, so I highly encourage you to look at it!

* November 27th - Released version 5.6 which includes minor quality of life improvements as well as improvements to canceling futures from threadly monads. As always the details are included in the full release notes.

* October 31st - Patch version 5.5 to address low priority tasks not completing on scheduler shutdown. There is no javadocs for this release due to there being no API changes.

* October 21st - Incremental version released, version 5.4 is now in maven central.

* July 22nd - Released version 5.2 that includes performance improvements in ListenableFuture/RunnableListenerHelper and ExecutorLimiter. Changes are mostly simple, but with 5.X we plan to release more frequent but smaller releases. Because of that we are trying to reduce some extra processes.

* July 2nd - Patch version 5.1 fixes regression in 5.0 PriorityScheduler where threads may forever go idle. This is a regression due to an optimization when interactions with other blocking actions using LockSupport. It is critical that all 5.0 usage is upgraded to use version 5.1 or newer.

* June 28th - After months of work, released version 5.0! This is easily the best threadly yet. It does require the use of java 8 and newer, but that means we are also able to take advantage of java 8 performance improvements and ergonomic improvements. I have been hesitant to release this because there is still so much more I want to do. Other projects like auroraArc have been taking more of my time. That said, I do plan to bring some improved documentation and benchmarks out soon. Right now the wiki is the best source of information, but if anyone would like to help improve this website it would be greatly appreciated!.