您的 Java 低延迟应用程序开发清单是什么？
我想为 Java 低延迟应用程序创建全面的清单。您可以在此处添加您的清单吗？
这是我的清单
1. 使你的对象不可变
2.尽量减少synchronized方法
3. 锁定顺序应有据可查，并谨慎处理
4. 使用分析器
5.利用Amdhal定律，找到顺序执行路径
6. 使用 Java 5 并发实用程序和锁
7. 避免线程优先级，因为它们依赖于平台
8.可以使用JVM预热
9. 更喜欢不公平的锁定策略
10.避免上下文切换（多线程会导致适得其反）
11.避免装箱、拆箱
12.注意编译器警告
13. 线程数应等于或小于核心数
低延迟应用程序每毫秒进行调整。
I would like to create comprehensive checklist for Java low latency application. Can you add your checklist here?
Here is my list
1. Make your objects immutable
2. Try to reduce synchronized method
3. Locking order should be well documented, and handled carefully
4. Use profiler
5. Use Amdhal's law, and find the sequential execution path
6. Use Java 5 concurrency utilities, and locks
7. Avoid Thread priorities as they are platform dependent
8. JVM warmup can be used
9. Prefer unfair locking strategy
10. Avoid context-switching (many threads lead to counter productive)
11. Avoid boxing, un-boxing
12. Give attention to compiler warnings
13. Number of threads should be equal or lesser than the number of core
Low-latency application is tuned for every milli-seconds.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（12）
尽管不变性很好，但它并不一定会改善延迟。确保低延迟可能取决于平台。
除了一般性能之外，GC 调优也非常重要。减少内存使用将有助于GC。特别是如果您可以减少需要移动的中年对象的数量 - 使其对象要么长期存在，要么短期存在。还要避免任何东西接触烫发根。
Although immutability is good, it is not necessarily going to improve latency. Ensuring low-latency is likely to be platform dependent.
Other than general performance, GC tuning is very important. Reducing memory usage will help GC. In particular if you can reduce the number of middle-aged objects that need to get moved about - keep it object either long lived or short lived. Also avoid anything touching the perm gen.
避免装箱/拆箱，如果可能的话使用原始变量。
avoid boxing/unboxing, use primitive variables if possible.
在消息处理路径上尽可能避免上下文切换
结果：使用NIO和单事件循环线程（反应堆）
Avoid context switching wherever possible on the message processing path
Consequence: use NIO and single event loop thread (reactor)
购买、阅读并理解Effective Java。另外在线提供
Buy, read, and understand Effective Java. Also available online
避免大量锁定和多线程，以免破坏现代处理器（及其缓存）的增强功能。然后，您可以使用单个线程达到令人难以置信的极限（每秒 600 万个事务），并且延迟非常低。
如果您想了解真实世界的低延迟 Java 应用程序及其架构的足够详细信息，请查看 LMAX：
LMAX架构
Avoid extensive locking and multi-threading in order not to disrupt the enhanced features in modern processors (and their caches). Then you can use a single thread up to its unbelievable limits (6 million transactions per second) with very low latency.
If you want to see a real world low-latency Java application with enough details about its architecture have a look at LMAX:
The LMAX Architecture
测量，测量，再测量。使用尽可能接近实际的数据和尽可能接近生产的硬件来定期运行基准测试。低延迟应用程序通常最好被视为设备，因此您需要考虑部署的整个盒子，而不仅仅是特定的方法/类/包/应用程序/JVM 等。如果您不在生产环境中构建现实的基准（例如设置），您将会感到惊讶生产。
Measure, measure and measure. Use as close to real data with as close to production hardware to run benchmarks regularly. Low latency applications are often better considered as appliances, so you need to consider the whole box deployed not just the particular method/class/package/application/JVM etc. If you do not build realistic benchmarks on production like settings you will have surprises in production.
不要在应用程序中安排比底层硬件上的内核数更多的线程。请记住，操作系统将需要线程执行，并且可能需要共享相同硬件的其他服务，因此您的应用程序可能需要使用少于可用核心的最大数量。
Do not schedule more threads in your application than you have cores on the underlying hardware. Keep in mind that the OS will require thread execution and potentially other services sharing the same hardware, so your application may be requried to use less than the maximunm number of cores available.
我认为“仅在适当的情况下使用可变对象”比“使对象不可变”更好。许多延迟极低的应用程序都有重复使用的对象池，以最大限度地减少 GC。不可变对象不能以这种方式重用。例如，如果您有一个 Location 类：
您可以在启动时创建一些类并一遍又一遍地使用它们，这样它们就不会导致分配和后续 GC。
不过，这种方法比使用不可变位置对象要棘手得多，因此应该只在需要的地方使用它。
I think "Use mutable objects only where appropriate" is better than "Make your objects immutable". Many very low latency applications have pools of objects they reuse to minimize GC. Immutable objects can't be reused in that way. For example, if you have a Location class:
You can create some on bootup and use them over and over again so they never cause allocations and the subsequent GC.
This approach is much trickier than using an immutable location object though, so it should only be used where needed.
生成大型字符串时，请使用
StringBuilder而不是String。例如查询。Use
StringBuilderinstead ofStringwhen generating large Strings. For example queries.另一个重要的想法是首先让它工作，然后测量性能，然后隔离所有瓶颈，然后优化它们，然后再次测量以验证改进。
正如 Knuth 所说，“过早的优化是万恶之源”。
Another important idea is to get it working first, then measure the performance, then isolate any bottlenecks, then optimize them, then measure again to verify improvement.
As Knuth said, "premature optimization is the root of all evil".
除了此处建议的开发人员级解决方案之外，考虑加速 JIT 运行时（例如 Zing）和堆外内存解决方案（如 Teracotta BigMemory、Apache Ignite）以减少 Stop-the-world GC 暂停也非常有益。
如果某些 GUI 涉及使用二进制协议（如 Hessian）、ZERO-C ICE 而不是 Web 服务等，则非常有效。
In addition to developer level solutions advised here already it can also be very beneficial to consider accelerated JIT runtimes e.g Zing and off heap memory solutions like Teracotta BigMemory, Apache Ignite to reduce Stop-the-world GC pauses.
If some GUI involved using Binary Protocols like Hessian, ZERO-C ICE instead of webservice etc is very effective.