TCP客户端服务器
我有一个关于 TCP 客户端/服务器网络的问题。我正在尝试创建一个聊天应用程序。我的计划是让客户端通过网络发送 Conversation 对象（对象具有 String username 状态和 String currentMessage 状态）。我的问题是，每次发送消息时我都应该创建一个新对象吗？即每次我想发送新消息时调用Conversation类构造函数？或者我应该只是更新当前消息状态？我有这个问题，因为目前，我只是更新状态，发生的情况如下：
currentMessage 状态在客户端更新得很好，但是当我通过网络发送 Conversation 对象并尝试检索 currentMessage 状态时另一边我不断获得原始状态值。这是为什么呢？服务器一直引用我第一次发送的原始消息值？
PS我不想发布大量代码，所以我希望有人能大致了解我做错了什么
I have a question on TCP client / server network. Im trying to create a chat application. My plan is for the client to send Conversation objects across the network (object has a String username state and a String currentMessage state). My question is, should i be creating a new object each time i send a message? i.e call the Conversation class constructor each time i want to send a new message? or should i be just updating the currentMessage state?? I have this question because at the moment, i have it just updating the state and here is what happens:
The currentMessage state updates fine on the client side, but when i send the Conversation object across the network and try to retrieve the currentMessage state on the other side i keep getting the original state value. Why is this? The server keeps refering to the original message value i sent the first time??
PS I dont want to be posting reams of code so im hoping someone might have a general idea what im doing wrong
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我猜你正在使用 ObjectOutputStream 或类似的东西？
我自己前段时间也遇到过这个问题。当您第一次发送时，它工作正常，但之后就无法正常更新。
这是因为流保存了对象状态，如果再次发送它不会更新。
您需要使用 收到对象后使用reset()方法使其再次更新。
Im guessing you are using an ObjectOutputStream or something similar?
Had this problem my self some time ago. When you send the first time it works fine, but after that it doesnt update properly.
This is because the stream saves the object state, and if it is sent again it doesnt update.
You need to use the reset() method after you received an object to make it update again.
您是否使用 ObjectOutputStream 类来序列化您的 Conversation 对象？如果是这样，它将缓存您已经写入流的类，因此即使您在客户端更改值，每次写入该对象时，它都会发送一个指向该对象的指针，从而节省大量时间和带宽。不幸的是，这并不总是您的目标，因此您有两个选择：
您可以在此处阅读有关此内容的精彩文章。
我个人发现创建新对象比在每次写入之前（或之后）重置流更干净，但是如果您处于对象分配相当大并且您只更改之间的几个字段的情况网络写入，重置流可能会更好。
然而，这种优化可能最好推迟到项目后期进行，那时您可以进行一些真正的分析，看看哪种方法更适合您。我的建议是选择你最舒服的，然后继续前进，直到达到优化的关键点。永远记住，过早的优化是优秀编程的祸根！ :)
Are you using the ObjectOutputStream class to serialize your Conversation object? If so, it will cache classes that you've already written to the stream, so even when you change the values client-side, every time you write that object, it will send a pointer to that object, saving a great deal of time and bandwidth. Unfortunately, that's not always your goal, so you're left with have two choices:
You can read a great article about this here.
I personally find it cleaner to create new objects rather than be resetting the stream before (or after) every write, however if you're in a situation where the allocation of your object is rather large and you're only changing a couple fields between network writes, it may be better to reset the stream.
This kind of optimization, however, is probably best put off until later in your project when you can do some real profiling to see which works better for you. My advice is to pick whichever you're most comfortable with and move forward until you're at a point that optimization matters. Always remember, premature optimization is the bane of good programming! : )
您可以使用 flyweight 设计模式。
基本上，您可以拥有一个始终相同的对象。您将其包装在另一个对象中。
在您的情况下，您每次发送的对象都是相同的。您唯一要更改的是文本。
虽然我不确定您的代码是如何工作的，但我看到的方式是，(1)创建一个新对象每次发送或(2)创建一个并继续设置要发送的不同文本（这有点像享元）。
前一种方式，您可以预先分配大量信封，并在发送消息时逐个使用它们。这将提高性能。
至于你的其他问题，我同意马特和哈斯拉姆的观点。您发送的内容可能已被缓存，因此您需要刷新它，或者让 Java 知道它已更改。
You can use the flyweight design pattern.
Basically you can have an object that is always the same. You wrap it in another object.
In your case the object you send will be the same every time. The only thing you change is the text.
While I'm not sure how your code works, the way I see it is, (1) create a new object to send every time or (2) create one and keep setting different text to send in it (which is kinda like flyweight).
The former way, you can preallocate a large list of these envelopes, and consume them one by one as you send the message. This will improve performance.
As for your other question, I agree w Matt and Hasslam. What you're sending is probably cached so you need to refresh it, or rather let Java know it has been changed.