java安全 docker支持

jvm运行在docker之类的容器中会有哪些问题？
Docker之类容器和虚拟机非常相似：
Docker 并不是一种完全的虚拟化技术，而更是一种轻量级的隔离技术。如下图

虚拟机会独立运行一个操作系统，容器则没有，仅仅是使用隔离的技术；所以容器省略了虚拟操作系统的开销，实现了轻量级的目标；

Java 平台来说，容器带来了很多意外的困难，主要体现在几个方面：
第一，容器环境对于计算资源的管理方式是全新的，CGroup 作为相对比较新的技术，历史版本的 Java 显然并不能自然地理解相应的资源限制。
第二，namespace 对于容器内的应用细节增加了一些微妙的差异，比如 jcmd、jstack 等工具会依赖于“/proc//”下面提供的部分信息，但是 Docker 的设计改变了这部分信息的原有结构，我们需要对原有工具进行修改以适应这种变化。

JVM 根据系统资源（内存、CPU 等）情况，在启动时设置默认参数。这就是所谓的Ergonomics机制，例如：
JVM 会大概根据检测到的内存大小，设置最初启动时的堆大小为系统内存的 1/64；并将堆最大值，设置为系统内存的 1/4。
JVM 检测到系统的CPU核数，则直接影响到了 Parallel GC 的并行线程数目和 JIT complier 线程数目。
Java设置的默认参数很可能是基于错误信息而做出的。这就类似，我以为我住的是整栋别墅，实际上却只有一个房间是给我住的。

JVM 的一些原有诊断或备用机制也会受到影响。为保证服务的可用性，一种常见的选择是依赖“-XX:OnOutOfMemoryError”功能，通过调用处理脚本的形式来做一些补救措施，比如自动重启服务等。但是，这种机制是基于 fork 实现的，当 Java 进程已经过度提交内存时，fork 新的进程往往已经不可能正常运行了。

如何解决上面的问题：-----使用最新版本的jdk
JDK9中引入了一些实验性的参数:如-XX:+UnlockExperimentalVMOptions
JDK10对容器（Docker）的支持已经比较完善：默认就会自适应各种资源限制和实现差异。

如果必须使用老版本的jdk，那就需要自己根据docker的配置，尽量具体设置jdk一些参数，包括:
堆大小、GC和JIT并行线程数等

java应用安全，涉及哪些安全机制？
1 运行时安全机制：
类的加载：验证Java语义和标准
双亲加载模型
2 Java 提供的安全框架 API
加解密API
HTTPS相关通信协议的红丝线
3 jdk集成的安全工具 
keytool 管理安全场景中的秘钥、证书等，并且可以管理Java程序使用的keystore文件。
jarsigner，用于对 jar 文件进行签名或者验证。

什么是安全漏洞?什么是注入攻击？
注入攻击
sql注入:参数中带有sql  '' or ''=''
操作系统命令注入： 原本执行 ls -al dir_name 输入的dir_name为 dir_name;rm -rf ./*
xml注入：

sql注入攻击解决：
输入阶段进行输入限制，如不允许标点符号等
preparestatement代替动态sql
数据库层面，对查询修改进行合理限制，查询的使用仅有查询权限账号；

DOS （Denial-Of-Service attack）
攻击者可以事先构造大量相同哈希值的数据，然后以 JSON 数据的形式发送给服务器端，服务器端在将其构建成为 Java 对象过程中，通常以 Hastable 或 HashMap 等形式存储，哈希碰撞将导致哈希表发生严重退化，算法复杂度可能上升一个数量级，耗费cpu，导致正常访问无法响应；
dos攻击如何避免？
使用最新的jdk，避免已暴露的问题，如hash碰撞
合理限制，如文件大小\如sql查询结果大小
资源释放，库连接、锁、流关闭

如何写出安全的java代码:
开发前的预设计 ：防注入、dos攻击的策略使用、token和调用策略
开发：
规范化:线程池自定义、流关闭、新版本jdk、map初始化大小
重要信息加密：注意防泄漏、传输加密、保存加密、序列化合理使用（transient保护关键信息）
代码优化：int溢出 if(a+b<c)--> if(a<c-b)

后期测试：
工具使用：findBugs工具分析