本文目录一览：
- 1、xsx和xss性能差距是什么？
- 2、java 异常at org.fenixsoft.oom.VMStackSOF.leak(VMStackSOF.java:20)
- 3、xss到手有多大内存
- 4、xss显存多少?
- 5、如何调整java虚拟机内存大小
xsx和xss性能差距是什么？
XSS使用传统的水平风道热管散热器，而不是XSX的均热板垂直风道，原因在于GPU部分热设计功耗少了一大坨，散热方面的压力没有XSX那么大，差别就是频率标定下调0.2GHz。
XSS在CPU核心数方面与XSX一致，GPU部分则大砍特砍，52CU砍到20CU，频率也被压低；内存由16GB减至10GB，主攻1440p@60FPS，吞吐率自然也 *** 了一倍多。最重要的次世代指标——游戏加载速度，以及CPU处理能力，两者基本一致。
相关介绍：
尽管XSS的非易失性存储空间打了对折（1TB降至512GB），但规格并未缩水，从而保证了两者的内容加载速度一致。在游戏开发业者看来，无需费时费力专为XSS优化；对玩家而言，也许画面观感不如XSX高大上，但使用体验方面不会失分太多。
PC爹爹可以回忆一下之一次用上SSD的情景：其它配置保持不变，仅将机械硬盘换成闪存固态盘，体验方面产生了怎样的飞越。也许那时候还在用集成显卡呢。
因此，定位低端的XSS似乎才是主机设计方面的典范：消除主要痛点，其它方面本着够用的原则一缩再缩，从而做到成本缩水而体验不缩水。
java 异常at org.fenixsoft.oom.VMStackSOF.leak(VMStackSOF.java:20)
先了解SOF的生成原因，以下为转载，可以自己百度。
Hotspot虚拟机并不区分VM栈和本地 *** 栈，因此-Xoss参数实际上是无效的，栈容量只由-Xss参数设定。关于VM栈和本地 *** 栈在VM Spec描述了两种异常：StackOverflowError与OutOfMemoryError，当栈空间无法继续分配分配时，到底是内存太小还是栈太大其实某种意义上是对同一件事情的两种描述而已，在笔者的实验中，对于单线程应用尝试下面3种 *** 均无法让虚拟机产生OOM，全部尝试结果都是获得SOF异常。
1.使用-Xss参数削减栈内存容量。结果：抛出SOF异常时的堆栈深度相应缩小。
2.定义大量的本地变量，增大此 *** 对应帧的长度。结果：抛出SOF异常时的堆栈深度相应缩小。
3.创建几个定义很多本地变量的复杂对象，打开逃逸分析和标量替换选项，使得JIT编译器允许对象拆分后在栈中分配。结果：实际效果同第二点。
VM栈和本地 *** 栈OOM测试（仅作为第1点测试程序）
/**
* VM Args：-Xss128k
* @author zzm
*/
public class JavaVMStackSOF {
private int stackLength = 1;
public void stackLeak() {
stackLength++;
stackLeak();
}
public static void main(String[] args) throws Throwable {
JavaVMStackSOF oom = new JavaVMStackSOF();
try {
oom.stackLeak();
} catch (Throwable e) {
System.out.println("stack length:" + oom.stackLength);
throw e;
}
}
}
运行结果：
stack length:2402Exception in thread "main" java.lang.StackOverflowError at org.fenixsoft.oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:20) at org.fenixsoft.oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:21) at org.fenixsoft.oom.JavaVMStackSOF.stackLeak(JavaVMStackSOF.java:21)这个应该和你遇到的问题一样，看看是不是存在以上3点的问题。
xss到手有多大内存
看你买的是多大内存。
微软终于在本周早些时候正式公布了XboxSeriesS，这是一台低配版的“XboxSeriesX”，但是价格非常便宜，人民币只要2000元左右。
主机公布以后，很多开发者对此表示了不满，因为这主机的内存比较低（XSS只有10GB的GDDR6内存，相比之下XSX有16GB），不利于开发工作。
但现在，看起来开发者们对XSS的评价并非都是负面的，一起来了解下。
xss显存多少?
xss 10g高低搭配显存，xsx 16g高低搭配显存。
显存速度xss比xsx低很多，游戏机没有内存，只有显存xbox series s的显卡相当于AMD的5500XT，如果是N卡的，大概相当于1650SUPER，不过不同架构的性能不能直接暴力的对比，但是最起码可以让玩家有一定的认识。另外本身主机的优化肯定更加好，所以在同个配置下，XSS的画面还是非常不错的。
处理器是基于AMD Zen2架构的定制版CPU，频率3.8GHz，显卡也是基于AMD未发布的RDNA2架构的定制核心，频率高达1.825GHz，具备52组CU单元，或者说3328个流处理器，浮点性能为12 TFLOP，比RTX 2080还强一点，另外还搭配16GB GDDR6，
如何调整java虚拟机内存大小
在一些规模稍大的应用中，Java虚拟机（JVM）的内存设置尤为重要，想在项目中取得好的效率，GC（垃圾回收）的设置是之一步。
PermGen space：全称是Permanent Generation space.就是说是永久保存的区域,用于存放Class和Meta信息,Class在被Load的时候被放入该区域Heap space：存放Instance。
GC(Garbage Collection)应该不会对PermGen space进行清理,所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误
Java Heap分为3个区
1.Young
2.Old
3.Permanent
Young保存刚实例化的对象。当该区被填满时，GC会将对象移到Old区。Permanent区则负责保存反射对象，本文不讨论该区。
JVM的Heap分配可以使用-X参数设定，
-Xms
初始Heap大小
-Xmx
java heap更大值
-Xmn
young generation的heap大小
JVM有2个GC线程
之一个线程负责回收Heap的Young区
第二个线程在Heap不足时，遍历Heap，将Young 区升级为Older区
Older区的大小等于-Xmx减去-Xmn，不能将-Xms的值设的过大，因为第二个线程被迫运行会降低JVM的性能。
为什么一些程序频繁发生GC？
有如下原因：
1.程序内调用了System.gc()或Runtime.gc()。
2.一些中间件软件调用自己的GC *** ，此时需要设置参数禁止这些GC。
3.Java的Heap太小，一般默认的Heap值都很小。
4.频繁实例化对象，Release对象 此时尽量保存并重用对象，例如使用StringBuffer()和String()。
如果你发现每次GC后，Heap的剩余空间会是总空间的50%，这表示你的Heap处于健康状态,许多Server端的Java程序每次GC后更好能有65%的剩余空间
经验之谈：
1．Server端JVM更好将-Xms和-Xmx设为相同值。为了优化GC，更好让-Xmn值约等于-Xmx的1/3。
2．一个GUI程序更好是每10到20秒间运行一次GC，每次在半秒之内完成。
注意：
1．增加Heap的大小虽然会降低GC的频率，但也增加了每次GC的时间。并且GC运行时，所有的用户线程将暂停，也就是GC期间，Java应用程序不做任何工作。
2．Heap大小并不决定进程的内存使用量。进程的内存使用量要大于-Xmx定义的值，因为Java为其他任务分配内存，例如每个线程的Stack等。
Stack的设定
每个线程都有他自己的Stack。
-Xss
每个线程的Stack大小
Stack的大小限制着线程的数量。如果Stack过大就好导致内存溢漏。-Xss参数决定Stack大小，例如-Xss1024K。如果Stack太小，也会导致Stack溢漏。
硬件环境
硬件环境也影响GC的效率，例如机器的种类，内存，swap空间，和CPU的数量。
如果你的程序需要频繁创建很多transient对象，会导致JVM频繁GC。这种情况你可以增加机器的内存，来减少Swap空间的使用。
4种GC
1、之一种为单线程GC，也是默认的GC，该GC适用于单CPU机器。
2、第二种为Throughput GC，是多线程的GC，适用于多CPU，使用大量线程的程序。第二种GC与之一种GC相似，不同在于GC在收集Young区是多线程的，但在Old区和之一种一样，仍然采用单线程。-XX:+UseParallelGC参数启动该GC。
3、第三种为Concurrent Low Pause GC，类似于之一种，适用于多CPU，并要求缩短因GC造成程序停滞的时间。这种GC可以在Old区的回收同时，运行应用程序。-XX:+UseConcMarkSweepGC参数启动该GC。
4、第四种为Incremental Low Pause GC，适用于要求缩短因GC造成程序停滞的时间。这种GC可以在Young区回收的同时，回收一部分Old区对象。-Xincgc参数启动该GC。
单文件的JVM内存进行设置
默认的java虚拟机的大小比较小，在对大数据进行处理时java就会报错：java.lang.OutOfMemoryError。
设置jvm内存的 *** ，对于单独的.class，可以用下面的 *** 对Test运行时的jvm内存进行设置。
java -Xms64m -Xmx256m Test
-Xms是设置内存初始化的大小
-Xmx是设置更大能够使用内存的大小（更好不要超过物理内存大小）
tomcat启动jvm内存设置
Linux：
在/usr/local/apache-tomcat-5.5.23/bin目录下的catalina.sh添加：JAVA_OPTS='-Xms512m -Xmx1024m'要加“m”说明是MB，否则就是KB了，在启动tomcat时会报内存不足。
-Xms：初始值
-Xmx：更大值
-Xmn：最小值Windows
在catalina.bat最前面加入
set JAVA_OPTS=-Xms128m -Xmx350m 如果用startup.bat启动tomcat,OK设置生效.够成功的分配200M内存.但是如果不是执行startup.bat启动tomcat而是利用windows的系统服务启动tomcat服务,上面的设置就不生效了,就是说set JAVA_OPTS=-Xms128m -Xmx350m 没起作用.上面分配200M内存就OOM了..windows服务执行的是bin\tomcat.exe.他读取注册表中的值,而不是catalina.bat的设置.解决办法:
修改注册表HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat Service Manager\Tomcat5\Parameters\JavaOptions
原值为
-Dcatalina.home="C:\ApacheGroup\Tomcat 5.0"
-Djava.endorsed.dirs="C:\ApacheGroup\Tomcat 5.0\common\endorsed"
-Xrs加入 -Xms300m -Xmx350m
重起tomcat服务,设置生效
weblogic启动jvm内存设置
在weblogic中，可以在startweblogic.cmd中对每个domain虚拟内存的大小进行设置，默认的设置是在commEnv.cmd里面。
JBoss
默认可以使用的内存为64MB
$JBOSSDIR$/bin/run.config
JAVA_OPTS = "-server -Xms128 -Xmx512"
Eclipse
在所在目录下，键入
eclipse.exe -vmargs -Xms256m -Xmx512m
256m表示JVM堆内存最小值
512m表示JVM堆内存更大
Websphere
进入控制台去设置：应用程序服务器 server1 进程定义 Java 虚拟机