RedSpider1/concurrent: a Chinese GitBook on Java concurrency, and how to read it locally

What RedSpider1/concurrent actually is

This is not a concurrency library and it does not ship a single class you can import. The repository holds a book: the README describes it as a series of articles on Java multithreading written and maintained by members of the RedSpider community. The prose lives under article/, the chapter order is fixed by SUMMARY.md, and the whole thing is assembled by GitBook into a website. The README states the motivation plainly: after reading existing material on Java concurrent programming, the authors found some points unclear, discussed them inside the community, and turned the discussion into a book. The stated sources are blogs, books and papers, with diagrams and demos added where an explanation was missing. The audience is therefore a Java developer who already writes code and wants the reasoning behind the concurrency utilities, not someone looking for a drop-in executor or a lock implementation. If you came here expecting an artifact, the first thing to understand is that the deliverable is reading.

How the book is assembled and served

The build chain is GitBook 3 driven by book.json, with SUMMARY.md defining the chapter tree and article/ holding the source text. The repository ships a Dockerfile that pins the base image to node:10.23.1-alpine3.9, copies the tree into /app/portal, installs gitbook-cli globally, runs gitbook install for the plugins, patches a copyPluginAssets.js file inside the installed GitBook 3.2.3 with sed, and starts gitbook serve. The patch rewrites confirm: true to confirm: false in that file, which suggests the default prompt blocked non-interactive asset copying in a container. That detail is worth noting: the image depends on the internal layout of GitBook 3.2.3, so a different GitBook release would leave the sed pattern unmatched. The port is declared with EXPOSE 4000, matching the localhost:4000 address in the README. Output is a static website; there is no server-side component, no database, and no runtime for the book's subject matter. The .drone.yml file in the repository root indicates CI was configured through Drone, and package-lock.json pins the npm dependency tree used for the plugins.

Installing GitBook and serving the book on localhost:4000

The README gives a local workflow. First install the GitBook CLI globally with npm, then let GitBook install the plugins declared in book.json, then serve the directory. The commands below are copied from the README as written.

npm install gitbook-cli -g

gitbook install

gitbook serve .

After gitbook serve starts, the README says the book is reachable at http://localhost:4000. You should see the rendered table of contents from SUMMARY.md and the first chapter. The README also notes that a PDF exists at ./book.pdf but warns that PDF generation is cumbersome and is not regenerated on every commit, so it recommends the web version. If you prefer containers, the Dockerfile encodes the same sequence; note that it uses Node 10, so a local Node installation much newer than that may behave differently with gitbook-cli, and the README does not document a supported Node range.

Where this repository is the wrong tool

Nothing in the repository ties the content to a JDK version, a GitBook version beyond the pinned 3.2.3 in the Dockerfile, or a Java release date. A reader who needs to know how a specific API behaves on a current JDK will not find that guarantee here; the text is explanatory prose, and the README's errata section openly invites readers to open an issue about mistakes or inaccuracies, which is an admission that the text is not authoritative. The local toolchain is also a fragile path: gitbook-cli and GitBook 3 are old, the Docker image is built on Node 10.23.1, and the build depends on patching a file inside the installed GitBook version. If your goal is to consume the content, building it is unnecessary work, since the README points to two hosted versions. Finally, the book is written in Chinese, so a reader who cannot read Chinese gets nothing from it regardless of how the repository is built. Treat it as a study resource, not as a specification or a source of truth for production decisions.

Compared with reading a concurrency reference directly

The obvious alternative is the primary documentation and the specifications the book itself draws on. The README says the content comes from blogs, books and papers, quoting material that was already clear and adding diagrams and demos where it was not. That framing defines the difference in approach: a language specification or an API reference describes the contract of each class and method, while this book tries to explain the reasoning behind the concurrency utilities and to fill gaps the authors found in other explanations. A specification will tell you precisely what a method guarantees; the book will tell you why the mechanism exists and how the pieces fit, in Chinese, with the authors' own diagrams. The trade-off is authority. A reference is maintained by the platform and versioned with it; this book is maintained by a community, and its errata section asks readers to report errors. If you need exact behaviour under a given JDK, read the reference. If you need the intuition first, read this, then confirm the details against the reference.

Maintenance, licence and what upgrading costs

The repository is not archived, and the last push was on 2026-07-10. That is recent enough that the project is not abandoned, but there is no release history, so there is no changelog to consult for what changed between versions of the text. The licence is MIT, recorded in LICENSE.txt. For a book repository, MIT means you can reuse and redistribute the text and the build files under the terms of that licence, including the attribution and licence notice; it says nothing about the accuracy of the content, and it is not legal advice. Upgrade cost is asymmetric. If you only read the hosted GitBook or the PDF, there is nothing to upgrade, and the README explicitly recommends the web version because the PDF is not regenerated on every commit. If you build locally, you inherit the GitBook 3 toolchain and the Node 10 base image in the Dockerfile, and the sed patch against GitBook 3.2.3 means a toolchain change is not a drop-in replacement. If you fork the book to write your own chapters, the cost is in the content, not the build: SUMMARY.md decides what appears, and article/ holds the text.

Editorial conclusion

Adopt it as reading material if you write Java and want a Chinese-language walkthrough of concurrency concepts, and use the hosted GitBook or the PDF rather than building the toolchain unless you intend to edit the text. Do not adopt it if you need an API, a dependency, or documentation pinned to a specific JDK version, because the repository contains prose and a static site generator, not code you compile against. Before you invest time, open the hosted version at concurrent.redspider.group and check that the chapters cover the topic you actually need, then confirm in SUMMARY.md which chapters exist, since the README's table of contents is not the authoritative list.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. RedSpider1/concurrent on GitHub