midlet 的线程安全检查变量
我正在客户端用 j2me 编写一个游戏，该游戏连接到用 java 编写的服务器。该游戏将有聊天功能，但作为次要功能。
对于连接到服务器的每个 midlet，都会生成一个服务器游戏线程。这些线程之间进行通信，以便它们可以同步并轮流写入服务器中的一系列配置文件。现在，如果在其中一个 midlet 中写入聊天消息，它就会传递到管理套接字通信的客户端线程并发送到服务器。在服务器中，同一游戏的所有其他玩家都会收到通知，并且聊天消息会转发给所有人。因此，每个服务器线程（但最初发送消息的用户线程）都会将消息发送到其对应的客户端线程。
我的问题来了。我如何向每个 midlet 发出信号，以便它知道有新的传入消息？
我考虑创建一个线程来轮询客户端通信线程以查看是否有任何新消息。但是，我怎样才能从 midlet 中知道，而不半途中断呢？理想情况下，我想直接读取客户端通信线程中的字符串，但该字符串可能正在被写入，因此我需要一个线程来访问它并与其同步。
你们中有人可以帮忙吗？我真的不知道如何继续，看来这应该非常简单......
提前致谢
I'm programming a game in j2me in the client side, that connects to a server written in java. This game is going to have a chat feature, but as a secondary feature.
For every midlet that connects to the server, a server-game thread is spawned. These threads talk between them, so that they can synchronize and write in turns to a series of config files in the server. Now, if a chat message is written in one of the midlets, it's passed along to a client-side thread that manages the socket communication and gets sent to the server. In the server, all other players of the same game are notified, and the chat messag is relayed to all of them. So every server thread (but the one of the user that sent the message originally) send to their correspondent client thread the message.
Here comes my question. How can I signal each midlet so that it knows there's a new incoming message?
I thought about making a thread that polls the client-side communication thread to see if there's any new message. But then, how can I know from the midlet, without interrupting it halfway? Ideally, I'd want to read directly a string that's in the client-side communication thread, but that string could be being written, so I need a thread to access it and synchronize to it.
Can any of you guys give a hand? I don't really know how to proceed, and it seems this should be pretty straightforward...
thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
你几乎从来不想进行民意调查。几乎在所有情况下，轮询都是一种严重的资源浪费。根据您建议的设计，每次轮询线程触发时都会进行上下文切换，这也将花费几个周期来检查是否应该处理请求。将轮询添加到网络代码中，您正在谈论一些严重的延迟。
使用观察者模式可以轻松解决您面临的问题。 （这里是来自patterndepot.org的该模式的 pdf 解释。这里是 JavaWorld.com 上的解释）另外在多线程环境中工作，轮询的缺点是上下文切换和同步，然后发现您不需要花费这些资源来检查消息总线。查看使用 java.util.concurrent 包来存储您的消息。
最后，您的总体架构听起来需要在服务器端进行一些修改。如果您计划拥有高用户负载，那么为每个用户引入新的中间层处理线程最终将导致服务器性能下降，因为您有更多的上下文切换，并且任务变得更加强大。
You almost never want to poll. Polling is a terrible waste of resources in almost every case. With the design you are suggesting, you are going to have a context switch every time the polling thread triggers, which will also then take a few cycles to check if it should process the request. Add polling to network code, and you are talking about some serious delays.
The problem you are facing is easily resolved using the Observer pattern. (Here is a pdf explanation of this pattern from patterndepot.org. Here is an explanation on JavaWorld.com) Additionally, working in a multi-threaded environment, polling has the disadvantage of a context switch, and synchronization, and then finding out that you didn't need to spend those resources on checking your message bus. Look at using a concurrent collection out of the java.util.concurrent package to store your messages.
Finally, your general architecture sounds like it will need some reworking on the server side. If you plan on having a high user load, as the introduction of a new mid-tier handling thread for each user will eventually cause the server performance to degrade, as you have more context switches, and tasks become beefier.
不幸的是，由于移动电话一生中的大部分时间都不会连接到互联网，因此唯一可用的真正推送机制是通过
PushRegistryAPI 实现的 SMS/MMS。真正的推送的真正问题是服务器需要一种方法来识别客户端，并且您不能依赖移动网络运营商为您的手机提供的临时 IP 地址。如果您计划使用 HTTP 连接通道，则需要轮询服务器以获取聊天消息更新。然而，有一些方法可以减轻这种糟糕的情况。
如果您的游戏应该定期向服务器发送数据/从服务器接收数据，您可以将聊天数据捆绑到 http 请求和回复正文中您自己的协议中。
从技术上讲，您可以通过使用 SMS 推送来触发 HTTP 数据检索来混合这两种方法，但这可能会变得昂贵。
关于在 MIDlet java 代码中正确使用
synchronized关键字，我建议您提出一个更精确的问题，并包含代码示例，因为它是一个不同的问题域。Unfortunately, since mobile phones generally do not spend most their whole life connected to the internet, the only true push mechanism available is SMS/MMS via the
PushRegistryAPI. The real problem with true push is that the server needs a way to identify the client and you can't rely on a temporary IP address given to your handset by the Mobile Network Operator.If you plan on using an HTTP connection channel, you NEED to poll the server for chat message updates. However, there are ways to make this less of a bad situation.
If your game is supposed to regulary send/receive data to/from the server anyway, you can bundle the chat data into your own protocol in the body of the http requests and replies.
You can technically mix the two approaches by using SMS push to trigger the HTTP retrieval of data but that can become expensive.
About the proper use of the
synchronizedkeyword in your MIDlet java code, I suggest you ask a more precise question, with included code sample as it is a different problem domain.