Java更新程序配置

发布于 2024-11-24 17:29:23 字数 261 浏览 2 评论 0原文

我有一个多线程程序,在启动时加载其配置。然后配置通过线程的构造函数传递给线程。

但现在我想定期加载一个新的配置实例,并将其传递给线程。

一种想法是使线程类中对配置文件的引用可变。然后,当更新的配置实例可用时,调用更新 update(Config c) 方法。

这是要走的路吗?我的性能会很糟糕,因为每次线程需要一些设置时,它都必须执行所有易失性检查。

有一些更好的建议吗?最佳实践?也许不要让它变得易失,并希望处理器不时从主内存中获取该新对象?

I have a multithreaded program that loads its configuration on startup. The configuration is then handed down to the threads via their constructors.

But now I want to load one new config instance regularly, and pass it to the threads.

One idea would be to make the reference in the thread class to the config file volatile. Then, when an updated config instance is available, call a update update(Config c) method.

Is this the way to go? I will have terrible performance because every time the thread needs some setting it has to do all that volatile checking stuff.

Some better suggestions? Best practice? Maybe don't make it volatile and hope that the processor fetches that new object from main memory from time to time?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

情话难免假 2024-12-01 17:29:23

您可以将所有配置值封装在一个不可变对象中,当配置更改时创建该对象的新实例,并通过侦听器或显式调用将其传递给线程。该对象没有易失性字段,只有对象本身可以写入易失性变量(或AtomicReference)。

没有其他同步机制的直接易失性方法是危险的:您可能会读取半重写的配置。

无论如何,对应用程序的性能影响可能可以忽略不计。如果你发现这确实是一个瓶颈,稍后再考虑优化。

You could encapsulate all of your configuration values in a single immutable object, and when the configuration changes create a new instance of the object, and pass it to the threads, through listeners or explicit calling. The object has no volatile fields, only the object itself could be written in a volatile variable (or an AtomicReference).

The direct volatile approach with no other synchronization mechanisms is dangerous: you could read a halfway-rewritten configuration.

In any case, the performance impact on your application is likely to be negligible. Think about optimization later, if you find this is really a bottleneck.

烟酒忠诚 2024-12-01 17:29:23

事实上,你确定这会带来糟糕的表现吗?

如果 volatile 主要用于读取,那么它的性能还不错。我建议首先尝试 volatile 并测量性能下降情况,只有当情况很严重时才进行返工

如果您真的担心快速易失性读取 - 那么在线程中运行方法时,您可以检查超时 - 如果自上次配置读取以来已经过去了 60 秒 - 然后重新读取它。逻辑将从 update(Config c) 反转为

if(moreThan60SecondsPassed)
{
localConfig = configconfigHolder.getConfig();
}

另外,如果您将使用非易失性 - 您将不会获得一半的读取配置。危险在于您可能会让某些线程永远看不到更新的值(没有发生之前的关系)。

Bw,您是否考虑过在配置更新时重新创建线程?在这种情况下,您仍然可以通过构造函数传递配置。这取决于您想要更新配置的频率。

Actually, are you sure that will have terrible performance?

If volatile used mostly for reading it's performance is not that bad. I'd recommend to try volatile first and measure performance degradation and only if it's significant then do any rework.

If you are really worrying about rapid volatile reads - then in you run method in thread you could have check for timeout - if 60 seconds passed since last config read - then reread it. Logic will reversed from update(Config c), to

if(moreThan60SecondsPassed)
{
localConfig = configconfigHolder.getConfig();
}

Also, if you'll be using non volatile - you won't get half read config. The danger is that you could have some threads not see updated value forever (no happens-before relationship).

Bw, did you consider recreating threads on config update? In this case you still could pass config through constructor. It depends on how often you want to update configuration.

何以畏孤独 2024-12-01 17:29:23

您可以使用观察者模式通过侦听器向线程通知新配置。

您无法避免易失性检查。也许很昂贵(做一些性能测试),但你的程序会正确运行。

You can use observer pattern to notify the threads of new config via listeners.

There is no way you can avoid volatile checking stuff. Maybe is expensive(do some performance tests) but your program will run correctly.

旧夏天 2024-12-01 17:29:23

您可能需要查看公共配置

基于文件的配置的一个常见问题是在数据文件更改时处理数据文件的重新加载。如果您有长时间运行的应用程序并且不想在更新配置文件时重新启动它们,这一点尤其重要。 Commons Configuration 具有所谓的重新加载策略的概念,可以与基于文件的配置相关联。这种策略监视配置文件并能够检测更改。默认的重新加载策略是 FileChangedReloadingStrategy。它可以在基于文件的配置上进行设置,如下所示。

ManagedReloadingStrategy 是自动重新加载的替代方案。它允许在正在运行的应用程序上热重载属性,但仅在管理员请求时才允许。 refresh() 方法将强制重新加载配置源。

You may want to look at Commons Configuration:

A common issue with file-based configurations is to handle the reloading of the data file when it changes. This is especially important if you have long running applications and do not want to restart them when a configuration file was updated. Commons Configuration has the concept of so called reloading strategies that can be associated with a file-based configuration. Such a strategy monitors a configuration file and is able to detect changes. A default reloading strategy is FileChangedReloadingStrategy. It can be set on a file-based configuration as follows.

ManagedReloadingStrategy is an alternative to automatic reloading. It allows to hot-reload properties on a running application but only when requested by admin. The refresh() method will force a reload of the configuration source.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文