有多少 java 码农平时需要用到 jvm 调优和数据库调优？

性能不够时应用做负载均衡，数据做主从，然后项目就死了，不会再优化了………

也就调个内存大小和 gc 参数，其它都默认

Devops

至少会调个堆大小吧....

国内需要天天优化 jvm 的就那么几个公司,
大把小公司活都干不完, 那里有空玩什么 jvm ,
现在硬件这么便宜, 多加点内存,跑几个 jvm 不比往死里优化 jvm 来的快么?

Java 面试总被问到的问题。。。。
但是实际从来基本没动过，顶多改改堆大小啥的

过早优化是万恶之源，能跑得动，或者加硬件能解决的 ，尽量不要用人力去解决，

现在硬件老便宜了，实在不行就上云服务器，再不行，就做负载均衡， nginx 反代，多个 tomcat
共享 session 池，然后数据库 做读写分离，最后还不行的话，
这项目也就差不多死透了，要么交个大公司做，要么就扩大团队，招一堆 架构师来 :D

首先优化这事情，肯定不是运维部署这些人能干的，否则还要程序员干嘛?

你给它写个 O （ N3 ）的算法在哪里跑，顺带还把数据库的连接池给耗空了，业务量一上来，
运维再怎么优化 也只能干瞪眼啊

例如把 select xxx from tablexx where x in (xxxx)这样的业务逻辑
用 Java 代码写出来，把整张表读出来，然后给它 朴素排序一遍，再根据用户提交查找并集，
顺带给整张表做事务最高级别处理，整表加锁

我也读过一部分深入理解 JVM 虚拟机，不过 JVM 的实现，我们肯定是很难搞懂的，
但是大概了解下 GC ROOTS 方式之类还是可以的。

从实际出发，真正对 GC 延迟要求极高的系统，实际上并不适合 Java 来做， stop the world
（一般都是 C++，手动管理内存，这样的系统实时性才高，例如 股票金融系统的实时性 ）
无论你再怎么调优， JVM 的 GC 算法是虚拟机厂商的黑盒，它是不会让你碰的，
而绝大部分做 Java 需要调优的场景相当少，
极高性能需求的 肯定是 C/C++， 这些语言的开发者在有必要的时候，连内存管理器都是自己定制的
（例如 redis ，它的底层实现是 hashmap ，很多数据结构都是通过自定义内存管理器实现的）
（ Java 门槛一看就低多了，根本没办法定制内存管理器）
对实时性有一定的要求，也有 Java 市场，但是不多，绝大部分开发领域的 Java 开发者接触不到而已，

主流虚拟机根据书上的介绍描述是，
没有任何一个 JVM 的 GC 实现 可以避免 stop the world

数据库调优肯定得懂的啊，这你也让运维搞？

jvm 不是吊打一票动态语言的 vm

@q397064399 哥....整张表读出来，这表一大，分分钟给你搞跪啊，人查询都限制返回行数的，普通 IN 查询根本没有问题，只要不是条件参数太多

数据库调优不可避免吧，索引合理性， sql 合理性等等。 jvm 调整的比较少，但是也有。

@Infernalzero 我只是假设而已，全读出来 肯定跪了，这种情况 查询并集的情况 肯定是要用 sql 来完成的
sql 存储引擎后面的算法 比我的 O （ N2 ）肯定强啊

一般情况下你用个脚本语言性能都可以，性能不够时应用做负载均衡，数据做主从，然后就行了。 XD

大多数是等不到调优项目就挂了

也是哦。

@q397064399 这个是 过早优化是万恶之源

有， jvm 调优， sql 调优（比较少，在设计时候已经充分考虑好业务了），还有查看线程运行情况。

@q397064399 其实 GC 的实现还是相当公开的， openjdk 里面各种各样的 GC 都有算法论文，以及代码都是公开的，想怎么调就怎么调。
还有一个就是 stop the world 其实也是可以避免的， http://www.azulsystems.com/sites/default/files/images/c4_paper_acm.pdf 这篇论文就有说 azul 是如何实现一个 GC ，并将卡顿控制在 10ms 之内，也有金融公司用了他们 JVM 。

@neoblackcap 我不是很清楚，我读过一个章节，
深入理解 JVM 虚拟机 确实有一个章节 有讲过 能够避免 stop the world 的虚拟机

但是 GC 算法是如何实现我的就不清楚了？
GCROOTS 难道是 dfs 搜索 有向图？从堆栈模型来讲，所有的对象确实是形成了一个 有向闭环图

java 还是太弱，需要优化内存，你看 php 就不用。

业务量不够，大部分情况下用不到。。。

jvm 调优，看要怎么细致地调优了，太细致的话，人力成本就上去了，所以一般就调个堆栈内存和 gc 的一些参数，通过加机器能够解决的还是通过加机器解决好了。数据库调优，如果是 sql 层的调优，很简单，收益大，值得一做，数据库配置上的，没做过，不懂

换工作面试的时候...

开发的时候，做应用层很少碰到数据库“调优”，更多时候只是按照正确的方法去做或者去改，比如把查询写对而不是一堆 N ＋ 1 Query ，加正确合适的索引，把一些复杂统计操作从应用层迁移到数据库层实现。

@q397064399 这年头有认(na)真(qian)做的 GC 基本都有避免 stop-the-world 的方法，有的能做到 incremental （把暂停分割成一点点一点点），有的能做到 concurrent （几乎不需要暂停），没有 bug 的状况下这些 GC 暂停时间肯定不是随着堆大小 O(n) 的，做得好基本都控制在几十或者几 ms 内……当然这个是有代价的，一般相比起完全的 stop-the-world 回收都会有一定的滞后，换句话说就是牺牲了 GC 的吞吐量（ thoroughput ）来换取低延时（ latency ）……

另外这些 GC 大部分就算不开源起码也会发发论文的……不至于黑盒子……

@joyee azul 家的 Zing JVM ，在 TB 级内存上超低延迟， GC 用的是黑科技版的 C4 ， 21L 的链接就是论文

@q397064399 至于怎么避免 stop-the-world ，最流行的就是各种 barrier + safepoint 检查来为 incremental / concurrent GC 提供保障了……有的是 read barrier 有的是 write barrier 有的都用（楼上的 azul 论文就都用），只要能想办法保证回收的时候不碰活的内存就行……

@buliugu 嗯但是他们家的 GC 要达到最好的效果需要用他们家的 CPU ……（ read barrier 需要硬件支持才能做的好）

jvm 调优少,内存调整首当其冲...
数据库调优是时时刻刻,因为一句 SQL 就能把数据库搞完蛋...

@joyee 是啊，但是 azul 家的客户很多都是墙街大佬，那只是小钱

作为一个 Javaer ，都应该懂得这些，基本技能。 另外，谁来做这个事情，显得不重要了，重要的是有人做。做了的要比不做的收获多。。。这是个 “ You can you up ” 的时代。

看了几章《深入理解 Java 虚拟机》，然后是一头雾水。。感觉根本就不是我这种还未入门的小白该看的