我想这是不可能的。但我正在寻找分离我的服务的不同层的最佳方法，但能够快速访问层或没有IPC / RMI的开销。
我使用的主要编程语言是java，但如果需要可以使用C ++。
我们现在拥有的是托管数据库和访问控制的服务器。我们使用RMI为消费者提供数据请求。这很慢，并且不能很好地扩展。
我们需要目前没有的性能和可扩展性。
我们正在考虑的是使用基础数据库的分层架构，其上的访问控制以及通知客户端数据库更改的通知总线。 主要问题是我们想要避免/或最小化的通信开销。
是否有任何魔术线程可以在两个上下文（切换上下文）中运行并以这种方式共享信息。我知道简短的回答是否定的，但有哪些选择呢？
更新
我们的基础层将提供一个API，可用于创建将在顶部运行的插件。所以它不是我们拥有的固定收藏家/消费者。我们可以运行5-6个收集器和相同数量的消费者。
我们最多可以有1000名消费者。
答案 0 :(得分：1)
我的第一个建议是你应该买一本关于构建可扩展应用程序的书（或找一个在线教程），因为你似乎很丢失。
在进程之间共享一个线程在任何级别都没有意义 - 它没有意义，但你可以共享线程访问的数据，这可能是你想要的。
最快的方法是基于C的IPC（例如，共享内存，信号量等：Shmget）。你说你想要避免IPC的开销，但实际上，它不会比这更快。
但为什么你想要多个流程呢？如果您担心进程之间进行通信的开销，那么只需将您的线程放在一个进程中即可？没有理由你的不同层必须处于不同的过程中。
但无论如何，我不相信你原来声明RMI很慢而且不能扩展是完全正确的。如果它没有扩展，您可能没有使用正确的框架。也许您有一个问题，即服务器上只有一个RMI端点。您是否考虑过使用无状态会话bean的J2EE系统？
不知道你的要求，很难说。
答案 1 :(得分：0)
由于OS设计，通常不可能在两个进程之间共享线程。在两个或多个进程之间共享数据的问题通常通过共享文件，共享数据库或共享消息（反过来可以是同步或异步），让进程通过管道进行通信（例如在Linux中，甚至共享内存）来解决。您的场景描述不是很精确，您需要描述所有流程以及信息应该如何流动，什么触发信息流等等。
您很可能需要高性能的消息库，https://github.com/real-logic/Aeron/就是其中之一。但要获得准确的答案，您需要更好地描述您想要最小化的开销。
答案 2 :(得分：0)
如果您的目标是通知用户，则应考虑发布/订阅消息（pub / sub）。有许多中间件供应商提供这种架构，尽管大多数在生产场景中都很昂贵。对于开源，请查看http://redis.io/topics/pubsub。 （没有隶属关系。）