每当我编写一个新类时，我都会使用大量的类变量来描述类的属性，直到当我回过头来查看我输入的代码时，我看到了 40 到 50 多个类变量，无论无论它们是公共的、受保护的还是私有的，它们都在我定义的所有类中被广泛使用。
尽管类变量主要由原始变量组成，如布尔值、整数、双精度值等，但我仍然有一种不安的感觉，即我的一些具有大量类变量的类可能会对性能产生影响，尽管它们可以忽略不计或许。
但是尽可能合理，如果我考虑无限的 RAM 大小和无限的 Java 类变量，Java 类可能是 RAM 中无限大的内存块，该块的第一部分包含类变量分区，其余部分该块包含 Java 类中类方法的地址。有了这么多的 RAM，它的性能就非常重要。
但这并没有让我的感受比说的更容易。如果我们考虑有限的 RAM 但无限的 Java 类变量，结果会是什么？在性能很重要的环境中真正会发生什么？
并且可能会事先被提及，我不知道有很多类变量是否算作不好的 Java 实践，当所有这些变量都很重要并且所有类都已重构时。
提前致谢。
性能与对象具有的字段数无关。内存消耗当然可能会受到影响，但如果需要变量，您就无能为力了。不要太担心性能。使您的代码简单、易读、可维护、经过测试。然后，如果您发现性能问题，请测量和分析以查看它们的来源，并在需要的地方进行优化。
可维护性和可读性受对象具有的字段数量的影响。40 到 50 个字段是相当多的字段，这可能表明您的类自己做的太多，责任太多。将它们重构为许多更小的子类，并使用组合可能是一个好主意。
我希望我听起来不像是个混蛋，但在我看来，一个类中有超过 10 个属性通常是一个糟糕设计的暗示，需要说明理由。
性能方面，如果您经常需要所有这些属性，那么您将节省一些内存，因为每个对象也有一个标题。因此，您无需将每一个类都放在一个类中，而是节省了一些字节。
根据您使用的垃圾收集器，分配更大的对象可能会更昂贵（这对于 CMS 垃圾收集器是正确的，但对于并行垃圾收集器则不然）。更多的 GC 工作 = 更少的应用运行时间。
除非您正在编写一个高流量、低延迟的应用程序，否则使用更少的类（和使用更少的内存）所带来的好处将完全被维护所需的额外工作所淹没。
我在一个有很多变量的类中看到的最大问题是线程安全——在这种情况下，很难推断出不变量。阅读/维护这样的课程也将非常困难。
当然，如果你尽可能多地制作不可变的字段，那会好很多。
我尝试使用：越少越好，更易于维护。
我们总是被教导的一个基本原则是保持高凝聚力（一个班级专注于一项任务）和低耦合（班级之间的相互依赖性较小，因此一个班级的变化不会影响其他班级）。
在设计一个系统时，我相信重点应该更多地放在可维护的设计上，性能会照顾好自己。我认为一个类可以拥有的变量数量没有固定限制，因为这将严格取决于您的要求。
例如，如果我有一个要求，应用程序向学生推荐一门课程，而算法需要 50 个输入（分数、爱好等），那么这些数据是在一个班级还是多个班级中可用都没有关系，因为整个信息需要加载到 RAM 中以加快执行速度。
我再说一遍，注意你的设计，在一个类中保留不必要的变量（因为它会将不需要的信息加载到 RAM）或拆分成比需要更多的类（更多的引用和因此指针移动）都是有害的
1.我总是以此为准则。一个类应该只有一个改变的理由，所以它应该只做一件事。
2.牢记这一点，我采用了定义此类属性所需的那些变量。
3.我确保我的类遵循Cohesive principle，其中类中的方法反映了类名称。
4.现在在整理完所有内容之后，如果我需要一些其他变量来计算我的课程，那么我需要使用它们，我别无选择......而且在所有这些思考和工作进入创建课程之后，将是几乎不受一些附加变量的影响。
有时类变量用作静态最终常量来存储一些默认字符串，如产品名称、版本、操作系统版本等。甚至存储产品特定设置，如字体大小、类型等。这些静态变量可以保持在类级别。
如果您只想存储字段常量或喜欢很少更改的产品设置，您也可以使用 HashMap 而不是简单的类。这可以帮助您加快响应时间。
我想提两件事：1.所有实例变量都存储在RAM的堆区域中。2。所有静态变量都存储在非堆区域（具体的方法区域）中。
无论是什么类型的变量（实例或静态），最终都驻留在 RAM 中。
现在来回答你的问题。就实例变量而言，java 的内置垃圾收集器在大多数情况下都能很好地、真正有效地工作，以保持释放内存。但是，静态变量不会被垃圾收集。
如果由于类中的大量变量而高度关注内存问题，则可以求助于使用弱引用而不是传统的强引用。