Java:Singleton类中系统属性和类变量之间的区别是什么?

发布于 2025-02-10 00:39:05 字数 768 浏览 2 评论 0原文

我有一个单身班,看起来像这样的

public class Data {
    private static Data data;
    private List<String> list;
   
    private Data() {
       list = new ArrayList<>();
    }
   
    public static Data getInstance() {
         if (data == null) {
             data = new Data();
         }
         return data;
    }

    public void process() {
        //check timestamp value
        //process values from list
    }
}

时间戳记列表最后处理时。但是,我试图决定是否使用私有类变量记录它或创建系统变量,例如system.set.property(“ timestamp”,system.currentTimeMillis());并访问它。我的要求是我只想在数据类中访问此值,但是我正在运行使用data.process的另一个类(例如dataAccessor)的多个实例。我想获得时间戳的最新价值,无论dataAccessor实例调用data.process,但我不确定通过系统属性与Singleton类中的本地变量之间的存储变量之间是否存在任何区别。

I have a singleton class that looks like this

public class Data {
    private static Data data;
    private List<String> list;
   
    private Data() {
       list = new ArrayList<>();
    }
   
    public static Data getInstance() {
         if (data == null) {
             data = new Data();
         }
         return data;
    }

    public void process() {
        //check timestamp value
        //process values from list
    }
}

I want to maintain a timestamp for when the list was last processed. However I'm trying to decide whether to use a private class variable to record it or create a system variable like System.setProperty("timestamp", System.currentTimeMillis()); and access it. My requirements are that I want to access this value only within the Data class but I am running multiple instances of another class (say DataAccessor) that uses Data.process. I want to get the latest value of timestamp irrespective of which DataAccessor instance calls Data.process but I am not sure if there are any differences between storing variables through system property vs local variables in a singleton class.

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

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

发布评论

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

评论(1

无声情话 2025-02-17 00:39:05

没关系,就代码样式而言,这已经是可悲的,因此担心它似乎有些愚蠢。

那不是您制作单身人士的方式

如果您从多个线程调用getInstance(), 。只需写:

public class Data {
  private static final Data data = new Data();

  public static Data getInstance() {
    return data;
  }
}

您正在做的事情('懒惰'使单例实例)是双重无用的:

  • 只有您的代码'touch''类型(data),但它首先是有用的,但是却没有t呼叫getInstance()。这对于所有单身人士都是罕见的。
  • 仅当创建实例的成本很高时才有用。显然不是在这里。

这不是您将类命名

数据的方式不是很好的描述性。它的非描述性几乎是陈词滥调。更一般而言,班级代表了各种演员 - 应该是名词。例如,它应该是logStorage,例如,如果此内容的目的是存储日志,甚至更好的atmlogStorage如果它专门表示ATM的PRINTROLL 。具体。

这不是单身人士的良好利用,

可以想象一个正在运行两个分离的概念的系统,这两个概念都需要相同的记录功能。

无状态单例(示例:Java的collections文件类 - 他们没有字段或其他任何状态您可以修改的任何状态)总是可以的。像这样的状态单例通常不是。如果需要,请使用注射框架。

单例在编写测试时很难测试

您倾向于设置虚拟版本或以其他方式配置某些对象与在正常运行时的配置不同,并且通常希望能够反复创建事物(隔离测试),在正常情况下运行时,仅创建一次。 Singletons和“我写了一个单位测试”并不喜欢彼此。

那么,你该怎么办?

制作字段 - 如果可以的话,请修复其他所有内容。至少使用该字段,您稍后可以重构代码,并使拥有多个Data(希望您重命名)有可能,即使仅出于测试目的。系统属性:

  • 无法控制(任何代码都可以读取和编写它们 - 您无法控制它)。
  • 是无形的状态,因为大多数Java应用程序都不将Sysproperty Store使用 write 数据。因此,大多数工具不是为了处理它而写的。可以将调试工具设置为断点,如果某人更改字段,则很难在某些代码更改sysproperty上进行分解 - 需要在set> setProperty中设置有条件的断点,然后设置有条件的断点。在各种口味中,oof。
  • 是“单身人士”,不能从中重构,而一个领域本身并不是丝毫的(事实,只有一个班级的实例与该领域的实例成为单身人士,但是改变了这一方面和您的方面和您田野不再是一个。

It doesn't matter, and this is, as far as code style is concerned, deplorable already, so it seems a bit silly to worry about it.

That's not how you make a singleton

It won't actually be a singleton if you call getInstance() from multiple threads. Just write:

public class Data {
  private static final Data data = new Data();

  public static Data getInstance() {
    return data;
  }
}

What you're doing ('lazily' make the singleton instance) is double useless:

  • It's only useful in the first place if your code 'touches' the type (Data), but doesn't call getInstance(). This is rare for all singletons.
  • It's only useful if the cost of creating the instance is high. It clearly is not, here.

That's not how you name classes

Data is not very descriptive. It's almost clichéd in how non-descriptive it is. More generally a class represents an actor of sorts - it's supposed to be a noun. It should be LogStorage for example, if the point of this thing is to store logs, or even better AtmLogStorage if it's specifically representing the printroll of an ATM that logs cash it emitted. Be specific.

This isn't a good use of a singleton

It's feasible to imagine a system that is running 2 separated concepts that both need the same logging functionality.

Stateless singletons (example: java's Collections or Files classes - they don't have fields or otherwise any state that you can modify) are always fine. Stateful singletons, like this one, usually aren't. Use injection frameworks if you must.

Singletons are hard to test

When writing tests you tend to want to set up dummy versions or otherwise configure some object differently than you would at normal runtime, and you usually want to be able to repeatedly create things (to isolate tests) that, during normal runtime, is only created once. Singletons and 'I wrote a unit test' do not like each other.

So, what do you do?

Make the field - and fix everything else if you can. At least with the field you can later refactor your code and make it possible to have more than one Data (hopefully you renamed it), even if just for testing purposes. system properties:

  • Cannot be controlled (any code can read and write them - you have no control over it).
  • Are invisible state, in that most java apps do not use the sysproperty store to write data. Hence most tools aren't written to deal with it; debug tools can be set to breakpoint if someone changes a field, it's much harder to breakpoint them upon some code changing a sysproperty - requires having the java core sourcecode and setting a conditional breakpoint on the setProperty method which comes in various flavours, oof.
  • Are 'singleton' and cannot be refactored away from it, whereas a field is on its own not singleton in the slightest (the fact that there's only ever one instance of the class with this field makes it a singleton, but change that aspect and your field ceases to be one. That's good).
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文