最近跟着项目组在重构一个java实时系统。原来的一个service不知道什么原因写了洋洋洒洒的2000多行。经过我们的不懈努力，已经重构为若干函数。
重构的过程中一个问题我一直不解，我一直有将若干个函数封装成为一个类的想法，但是总是遭到反对意见，原因是实时系统中存在太多类会影响系统效率。我一直持怀疑态度，但是在google上找不到佐证，于是发帖讨个说法。请各位大虾踊跃发言。感谢！
重构的过程中一个问题我一直不解，我一直有将若干个函数封装成为一个类的想法，但是总是遭到反对意见，原因是实时系统中存在太多类会影响系统效率。我一直持怀疑态度，但是在google上找不到佐证，于是发帖讨个说法。请各位大虾踊跃发言。感谢！
A：不知道Java是不是也这样执行 因为中间有个虚拟机
B：PC跳转指令会严重影响执行效率，但是优化的编译结果往往会频繁使用PC跳转
C: A说的也有道理，如果这样的话时间就差别在保留当前场景和复位上了。不知这细微的差别对实时系统的影响有多大。
方法使用完了就释放？？？
JAVA的垃圾回收可不像C那样子的，
你即使调用了GC的垃圾回收方法，JVM也并不一定马上就会垃圾回收，
调用该方法只是建议JVM回收该垃圾，建议而已
不过由代码的可读性来说2000多行的代码放在一个类中的确是过多。经验告诉我，能独立的模块还是独立的好。
jvm需要查找类，查找该名字的类方法，然后才是真正调用函数；
而放在同一类中，可能就不需要查找类这步。
另外，jvm运行时，每个已加载的类都要有记录信息，潜在增大了内存占用。不过我个人是反对仅从类多少、函数调用次数多少的角度看效率的，觉得应根据开销比例来看问题。
比如调用其它的类方法，假如是按照上面所讲的步骤来执行，“查找类”的开销，相对于查找方法名、调用、方法内的具体代码这些的总开销，比例一般很少，不会成为影响性能的关键。
过多的类会导致对象的创建和销毁的时间开销。提问：
对象的创建和销毁开销和对象的那些属性相关？
有这么几种对象
一 属性很多，方法只有getter和setter的POJO
二 没有属性，仅提供方法的Service对象
三 只有一个或少量属性的service对象这几种对象的创建和销毁的开销：
A 差不多
B 类型一的对象比较多
C 类型二的对象比较多
D 类型三的对象比较多