SurvivorRatio = 8意味着每个幸存者空间占用年轻一代的1/8，其大小为Eden + To + From。在您的情况下，年轻一代的大小为1365.5 MB，其1/8将是170，69-假设有一些舍入（或其他小空间），这些值是合理的。

**更新：**我在这里有一些误解。在你的情况下，值是有效的，空间可能还没有使用它们的最大容量。

尝试使用Xms=<value of Xmx>运行测试。
在我的例子中（使用jdk 1.6、1.7和1.8），我使用SurvivorRatio=10并得到以下结果（Java 8有一些细微的差异）：

Heap Configuration:
  ...   
  SurvivorRatio    = 10
  ...

Heap Usage:
PS Young Generation
Eden Space:
  capacity = 596508672 (568.875MB)  //Java 8 reported 569.5 here
  used     = 536159440 (511.3214874267578MB)
  free     = 60349232 (57.55351257324219MB)
  89.8829246190741% used
From Space:
  capacity = 59637760 (56.875MB)    //Java 8 reported 56.5 here
  used     = 59626360 (56.86412811279297MB)
  free     = 11400 (0.01087188720703125MB)
  99.9808845939217% used
To Space:
  capacity = 59637760 (56.875MB)    //Java 8 reported 56.5 here
  used     = 0 (0.0MB)
  free     = 59637760 (56.875MB)
  0.0% used

字符串
正如你所看到的，两个幸存者空间的大小都是伊甸园空间的10%。没有Xms=<Xmx>，我得到的百分比要低得多，因为空间还没有增加。

更新二：

显然OP的空间已经获得了最大容量，年轻一代最大容量为1365 MB（这是4096 MB最大堆大小的33%）。（即每个幸存者空间占用伊甸园空间的1/8）但jmap报告的比率为8表示此处存在某种错误/bug（我用JVM版本21.0-b17和25.40-b25进行了测试，即OP的版本24.80-b11介于两者之间）。

更新三：

我用jdk 7重新运行了两次测试：
No 1.：未设置SurvivorRatio，即应使用默认值8：

Heap Configuration:
   ...
   SurvivorRatio    = 8
   ...

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 536870912 (512.0MB)
   ...
From Space:
   capacity = 89456640 (85.3125MB)
   ...
To Space:
   capacity = 89456640 (85.3125MB)
   ...

型
No 2.：explicit SurvivorRatio=8 set：

Heap Configuration:
   ...
   SurvivorRatio    = 8
   ...

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 572653568 (546.125MB)
   ...
From Space:
   capacity = 71565312 (68.25MB)
   ...
To Space:
   capacity = 71565312 (68.25MB)
   ...

型
正如你所看到的，尽管两种情况下都报告了值8，但比率还是有区别的。只有第二种情况下比率被显式设置为8，符合文档中提供的公式，这表明在默认情况下使用了其他比率，jmap要么报告了错误的比率，要么实际的大小计算使用了不同的值/公式。
根据这些值，公式如下所示：

• 显式存活率：size(survior space) = size(eden space)/survivorRatio（示例：546.125 / 8 = 68.25-参见测试2）
• 隐式/默认幸存者比率：size(survior space) = size(young generation)/survivorRatio（示例：682 / 8 = 85.25-参见测试1，值四舍五入）

注意：jdk 1.8也是如此。

你的伊甸园与幸存者的比例是6：1，因为有两个幸存者，幸存者与年轻空间的比例是1/8。
Eden的容量为1024.5 MB，1024.5 / 6 = 107.75，非常接近每个幸存者空间的107.5 MB。

为了扩展并澄清Thomas's answer中所述的行为，两种情况下的差异是由于显式指定SurvivorRatio标志和不指定相同标志的情况的处理方式。剧透警告- jmap输出（即SurvivorRatio = 8）也不是完全错误的。你会问为什么？沿着：
有3个与生存率相关的选项-SurvivorRatio，MinSurvivorRatio和InitialSurvivorRatio。这些选项的默认值（可以在源代码gc_globals.hpp中找到）分别为8，3和8。从源代码中可以清楚地看到：

• SurvivorRatio考虑比率Eden：Survivor
• MinSurvivorRatio和InitialSurvivorRatio考虑了年轻一代：幸存者的比例

根据this Oracle错误单，
垃圾邮件收集器使用命令行标志MinSurvivorRatio和InitialSurvivorRatio。
(Note实际上Parallel scavenge是GC的名称，而Parallel scavenge是明确告诉JVM使用此GC的标志。
根据this Oracle错误单，
SurivorRatiok的值将产生InitialSurvivorRatio=(k+2)和MinSurvivorRatio=(k+2)，如果是Parallel Scavenger
（源代码：parallelArguments.cpp）（并行清除器是默认的GC。从代码中可以看出，只有在指定了SurivorRatio但未指定这两个标志时，才会以这种方式为这两个标志赋值。）
如果没有指定SurvivorRatio和其他两个标志，则将使用gc_globals.hpp中指定的默认值。并行Scavenger只关心MinSurvivorRatio和InitialSurvivorRatio的默认值。
因此，我们认为，

• 如果指定了SurvivorRatio=8选项（其他两个选项未指定），（k+2=10），则它将生成最小和初始YoungGen：Survivor比率为10：1
• 如果未指定3个标志中的任何一个（无修改，使用默认值），则其产生初始（和最小）YoungGen：Survivor比率为8：1（和3：1）。

在这两种情况下，SurvivorRatio的值都是8，因此jmap将输出8。
这个答案假设XX:UseAdaptiveSizePolicy标志被禁用（显式地，因为它在默认情况下是启用的），因为根据IBM docs：
避免麻烦：-XX：SurvivorRatio=选项与JVM参数-XX：+AdaptiveSizePolicy不兼容。请根据您的情况使用其中一个。

似乎在某个时候，伊甸园/幸存者空间大小的计算公式已经改变了。
参见https://searchcode.com/codesearch/view/17980811/，第52至54行：
幸存者比率是“原始”计算的，不像默认的gc，它在比率值上加2。我们需要在使用它们之前确保这些值是有效的。