场景： 构建Android项目，爆出【 Could not reserve enough space for 2097152KB object heap 】，JAVA虚拟机内存不足。 之前是认为是windows问题导致macOS下开发的项目在构建时出错，调整了项目的gradle的jvm内存大小为1G。
指定gradle的JVM内存方案
修改【gradle.properties】文件
org.gradle.jvmargs=-Xmx1024m -XX:MaxPermSize=1024m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
后仔细排查问题后发现原因为本地JDK版本非64位，这是导致该问题的根本原因。
在32位的Java虚拟上想调用超过4GB的heapsize肯定是不行的
紧接着去下载了64位的JDK，对Jenkins服务进行了停服，升级本地JDK.
操作完毕后，重启Jenkins又出现整个Jenkins变成了初始化的状态，安装的组件也丢失了，Job任务也丢失了，仿佛一切都需要重新配置。。。
继续查找问题后发现，是由于JDK从32位升到64位后，Jenkins在windows下的目录也发生了变化。
从 C:\Windows\SysWOW64\config\systemprofile\AppData\Local\Jenkins 变更到了 C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins
再次停服搬运AppData\Local\Jenkins下内容恢复正常。
扩展两个问题
Windows64bit系统 兼容32位应用的策略
C:\Windows\SysWOW64 ：存放兼容32位应用的数据目录
C:\Windows\System32 ：存放64位应用的数据目录
至于为什么名字起的这么别扭，微软官方文档给出了解释
因为这是Windows系统的另一个兼容性方面的努力：让一个已有的32位应用程序，不加修改或者尽可能少地加以修改，便可以被编译成64位应用程序并在64位Windows上运行。其实，把System32这样的路径，写死在程序里，并不是一个个案。所以，为了保证这些应用程序可以顺利地过渡到64位，Windows最后还是决定让64位的系统文件放在System32的文件夹下。而让32位的系统文件，搬到了SysWow64中去。
相关链接：docs.microsoft.com/zh-cn/archi…
扩展话题关于JDK版本选用。
目前甲骨文的JDK下载不太方便，且存在潜在的商业侵权风险，可有如下版本的OpenJDK进行替代和下载。
Azul zulu OpenJDK: www.azul.com/downloads/?…
华为-毕昇JDK ：www.hikunpeng.com/developer/d…
Amazon Corretto JDK: aws.amazon.com/cn/corretto…
各有各的新特性
