zmal 最近的时间轴更新 zmal 最近的时间轴更新 |
zmalV2EX 第 407835 号会员，加入于 2019-04-30 11:34:03 +08:00今日活跃度排名 7735 |
| Springboot3 + JDK17 可以上生产环境了吗？ 程序员 • zmal • 95 天前 • 最后回复来自 WeiYuanStudio | 17 |
zmal 最近回复了
16 小时 14 分钟前 回复了 Sam99 创建的主题 › 程序员 › == > < 在 JavaScript 这三种运算哪个更消耗 cpu 和内存 ，以及所用时间 ？ |
盲猜是==
16 小时 21 分钟前 回复了 dxatgp02 创建的主题 › Java › Java 对象里为什么要用 get set? |
op 好奇的可能是为什么纯数据实体也要用 getter/setter ，这要从 Java 的一切皆对象说起了，涉及到当时的语言设计思想，略过不表。
本质上是因为在 Java 中没有结构体这种纯数据实体结构，jdk17 的 record 也只是对象的语法糖。结构体可能在 jdk18 或 19 加入。
本质上是因为在 Java 中没有结构体这种纯数据实体结构，jdk17 的 record 也只是对象的语法糖。结构体可能在 jdk18 或 19 加入。
1 天前 回复了 eryajf 创建的主题 › 程序员 › [交流] 最近在看前端的内容，接触了一些前端的代码，有一些吐槽 |
op 吐槽的其实都是 js 的问题。
js 最开始只是想做个脚本语言，弱类型写法多变没啥不好。结果前端发展过于迅猛，很快面临了工程化问题。js 的各种弱点暴露的比较明显。
你吐槽的东西大部分能用 js 类型补丁语言：ts 来解决。ts 写起来挺爽的。
js 最开始只是想做个脚本语言，弱类型写法多变没啥不好。结果前端发展过于迅猛，很快面临了工程化问题。js 的各种弱点暴露的比较明显。
你吐槽的东西大部分能用 js 类型补丁语言：ts 来解决。ts 写起来挺爽的。
2 天前 回复了 badboy17 创建的主题 › Java › Java 求解答：为什么 JackSon 和 fastJson 里使用 string.intern，欢迎美团技术团队解答:-) |
对你说的 ygc 变慢是 intern()引起的说法存疑。
2 天前 回复了 badboy17 创建的主题 › Java › Java 求解答：为什么 JackSon 和 fastJson 里使用 string.intern，欢迎美团技术团队解答:-) |
当 stringtable 里的字符串被复用的时候就节省时间了呗，intern() 不就是做这个的嘛。
5 天前 回复了 yourmoonlight 创建的主题 › 程序员 › 最近忽然有种感觉， web2 的应用逐渐在腐朽崩塌，但新的应用形式是什么样，又还看不清楚。不知道大家有什么想法吗，可以一起来说说呀。现存的痛点究竟是什么，我们该怎么建设出一个更好的？ |
技术不是银弹，和 web2 没啥关系。
6 天前 回复了 jeodeng 创建的主题 › 程序员 › 请教一下，前端真的会有算法诉求吗？ |
需要。就比如一个目录树，新手能写个 N 次方算法出来。
如果写小程序，或者老旧 windows 平台（医院自助服务机）这种对资源敏感的客户端，即使是 n^2 和 n*logn 都会体现出明显差距。
如果写小程序，或者老旧 windows 平台（医院自助服务机）这种对资源敏感的客户端，即使是 n^2 和 n*logn 都会体现出明显差距。
8 天前 回复了 cpalead 创建的主题 › Java › Java switch 为什么比 for 循环快？ |
反编译后的字节码很清晰了：编译优化成查表后把枚举类进行了标量替换，tableswitch 里的数字应该是直接放在方法栈里，避免了去堆里访问对象，所以快了很多。
9 天前 回复了 coderstory 创建的主题 › Java › Java 8 的 stream 常规操作导致线程卡死 |
线程卡死本身和 stream 没啥关系。
但这个代码写的实在是太辣了。stream 不是让这么用的。
但这个代码写的实在是太辣了。stream 不是让这么用的。
14 天前 回复了 hahaFck 创建的主题 › 程序员 › Java 关于数据库 Entity 如何设计 |
当你在 3 张表以上的 join 加一堆 where...on 时，已经是在 SQL 里写业务了。
联查最大的问题是制约了数据库设计，一般认为 mysql 单表几千万是上限，超过该规模考虑分表。联查的索引不易设计，很容易在业务规模还未扩大时就整出慢 SQL 。
所以三大范式在实际业务中很少遵守，往往是弱耦合 + 宽表的设计思路。数据规模再扩大就上列式存储，不会尝试在关系型数据库死磕。
当然一切都不是绝对的，如果你的 User 表几千条，Department 几十条，Organization 几十条，想怎么 join 都行。但还是建议在代码层解决问题，除非涉及到性能问题。
联查最大的问题是制约了数据库设计，一般认为 mysql 单表几千万是上限，超过该规模考虑分表。联查的索引不易设计，很容易在业务规模还未扩大时就整出慢 SQL 。
所以三大范式在实际业务中很少遵守，往往是弱耦合 + 宽表的设计思路。数据规模再扩大就上列式存储，不会尝试在关系型数据库死磕。
当然一切都不是绝对的，如果你的 User 表几千条，Department 几十条，Organization 几十条，想怎么 join 都行。但还是建议在代码层解决问题，除非涉及到性能问题。
Select Language