-xms -xmx无效

在查询生产问题时发现-xmx无效，jvm这个进程所产生的内存竟然远-远超出了-xmx，怎么回事？
以下是个人的推断，没有去认真学习操作系统的进程管理。在操作系统中能控制的一个进程所占用的大小肯定是在操作系统层面设置的（如果存在的情况的下），不然chrome也不会成为程序员又爱又恨的工具了，它可以吃到你的机器所有的内存。
因此在不设置进程内存大小的时候，-xmx肯定设置的jvm里的参数，千万不要觉实际内存是-xmx加点余量就是了。
xmx只是设置了jvm中java管理内存的head大小，记住jvm中head的内存肯定是根据jvm编排或者转换后的（个人猜测），这句话在你做mat内存泄露的时候非常关键。
实际内存是head+nonhead还有其他组成，nohead这里的内存编排应该就是根据操作系统的2进程编排的（个人猜测），所以不能做java mat。
这是导致–xms不能代表最小xmx不能代替最大内存的原因么？
不好意思，也不是！
或许写上层程序太多了，忘了底层的知识了，还记得大明湖畔的MMU么，是的就是在嵌入系统里的memory manager unit，应该是和操作系统相关的。
这个实际内存的使用时申请多少还系统分配多少，所以不少资深的开发人员还是误以为-xms就是最小的实际内存了。
其实 xms只是和系统说，皇上我需要那么大的湖畔，请分配给我，皇上呢，也确实做了湖畔规划，这一片都是你的了，但是只要你还没有游到50m，规划的1000m都是没有实际分配的。
那xms设置大了和设置小了有区别么？反正都是慢慢变大，有的。
xms特别下，gc肯定以规划的50m做你的gc策略，非得你不够用了才扩大，如果xms一开始就是设置大，gc肯定说尽情游泳吧，规划就这么大了。但是实际内存都是看你游到那里了感觉去跟政府申请实际使用资金赶紧挖湖。
今天先写到这里，不想写了