存储每个会话都需要但永远不会改变的数据的最佳方式答案

【问题标题】：Best way to store data that will be needed every session, but will never change存储每个会话都需要但永远不会改变的数据的最佳方式
【发布时间】：2016-10-15 15:34:39
【问题描述】：

我有一个包含大约 150 个条目的键和相应值的列表。我有一个方法可以在每个会话中多次访问它，但永远不会编辑它。每次会议都将保持不变。我想是因为我想快速访问这些值，我会使用哈希图，但我不确定如何长期存储它。存储它的最佳方式是什么，然后在我的程序开始时访问它。谢谢！

【问题讨论】：

创建一个单例类保存跨多个会话共享的值，充当内部缓存。'
redis 是最常见的方式。如果您希望扩展以存储数千个这样的键值对，那么 redis 将表现得非常好。否则，如果它是常量 150，则将其存储为 json 文件并在程序启动时对其进行解析。
为什么不能保存在内存中？是尺寸（或）其他问题吗？
如果你想考虑public static final的解决方案，@alex，你可以看看javapractices.com/topic/TopicAction.do?Id=2。
我想我可以，我只是想，因为我永远不需要更改数据，每次我的程序启动时我可以避免 150 .put() 调用，只需创建一次然后连续创建它访问它。

标签： java data-structures storage

【解决方案1】：

您似乎可以对其进行硬编码，例如带有地图字符串 -> 字符串：

  public final class CONST
  {
    public static final Map<String, String> DATA;

    static
    {
      final Map<String, String> data = new HashMap<>(200);

      data.put("key001", "value001");
      // ...
      data.put("key150", "value150");

      DATA = Collections.unmodifiableMap(data);
    }
  }

这会在加载类时创建哈希表。如果您出于某种原因想避免这种情况，您也可以使用initialization-on-demand holder idiom

【讨论】：

【解决方案2】：

如果它实际上永远不会改变，你不妨将它存储在一个静态初始化类中：public static final。如果我们假设它永远不会改变，那么就没有理由通过其他技术（例如从文件或数据库加载）来轻松改变它。

您可以将其存储为具有 150 个条目的 HashMap 还是一个类中的 150 个字段。我认为这取决于您要如何访问数据。如果您将其存储为 HashMap，那么您可能会访问 String 键上的值，例如Constants.getData("max.search.results")。如果您将其存储为 150 个字段，则只需直接访问这些字段，例如Constants.MAX_SEARCH_RESULTS.

至于性能，有 150 个条目，除非您的数据很大，否则您无需担心。人们经常使用 HashMaps 来处理数千或数百万个条目。

至于什么时候初始化，Java中的static字段只在应用启动时初始化一次。对于 150 个条目，这应该花费不到一毫秒（粗略估计）。

另见

【讨论】：

【解决方案3】：

从不从不？在这种情况下，您应该考虑将属性（或 JSON 等）文件构建到程序的 jar 中。然后你可以使用

new Properties(getClass().getResourceAsStream());

从与属性文件处于同一包级别的任何类中获取键值对集合。

如果实际上它可能偶尔会发生变化，您可能需要考虑某种外部数据存储，正如我在 cmets 响应您的问题中已经提到的那样。

【讨论】：

是的，从来没有。我将如何将其构建到 jar 文件中？
具体情况取决于您使用的是哪种构建工具（比如 ant 或 maven？只是 javac 和 jar？）但它可能归结为将它放在同一个目录中类文件在构建 jar 之前进入。我习惯于 maven，通常在 /src/main 下它会期望 /resources 与 /java 并列，然后具有并行包结构。
嘿抱歉。我对java很陌生，所以我没有完全理解这一点。我相信我知道如何添加 jar，但我不确定在哪里输入数据以获取 jar。我会创建一个包含它的对象然后保存它或类似的东西吗？
如果它真的永远不会改变，他还不如把它存储在一个静态初始化类中：public static final。如果我们假设它永远会改变，那么就没有理由让它变得容易改变。
这是一个合理的观点，并且省去了我用 cmets 施加的无换行符限制来解释将文件构建到 jar 中的过程的麻烦，所以我赞同这一点。