https://pebble-skateboard-d46.notion.site/Java-7d1e6f877c9d4d02811e1181bc5b361c?pvs=25 看我这篇文章吧，会对方法句柄和 Lambda 有一个更深的了解。

在线简历也蛮重要的，决定了 hr 看不看你要不要附件简历，不过在线的内容要相对比较浓缩很多不然缩略里面是不会全部展示的

这不就是 arthas 的 trace 嘛，直接搞过来。pinpoint 、jvm sandbox 等也可以抄一抄。

dubbo-admin 里面有根据接口签名和元数据生成示例参数的代码，核心逻辑就是解析 java.lang.reflect.Method#getGenericParameterTypes 中的泛型入参。
对于你来说第一步根据 method 签名中的泛型信息解析出来所需要的 java 类型，第二步生成随机参数可以使用 Podam ，试下来体验还可以。

@la2la 可以到杭州看看，苏州和武汉互联网不太行，当然互联网现在整体也不太行了，如果考虑制造业的一些 IT 需求可以去苏州。

不后悔，我这样的人不让我写代码我都不知道自己能干什么，如果现在失业可能只能去泡滴滴了。

没家庭的话去一二线赚钱攒钱吧，加油。

计算机的前景想必没人说得准，可以趁现在没孩子没房贷在工作上再努力一下，多考虑考虑家乡省会的一些工作机会，至于买房和国内游我觉得都还好，旅游本身没那么费钱，房价也还在下行像你也比较保守非核心小户型我觉得和你老婆一起努力是不成问题的。

没有简单的方案：
1.润，所有选择里面最长久和舒服的，到了国外你的学历焦虑会低很多，但语言是个迈不过去的坎；
2.卷开源，最好是 owner ，实在不行混一个明星开源项目的成员，这条路对技术和 idea 的要求非常非常高；
3.卷技术博客，相比于第 2 条技术要求相对低一些，但要求找准赛道发现需求，成了就可以获取技术影响力；
4.修心，不执着于互联网和大厂，认真思考赛道选择一个相对稳定的行业，人生不只有工作；

多试几个好了。Cfr 、Procyon 、jadx ，一般 Java 的代码很少加混淆也没那个价值

@whoami9426 very good

我一直有个想法没空去实现，对这种使用 copyProperties 方法的两个对象，解析其 class
1.比对两个 class 的字段，然后将差异列出来，比如 target 有但是 source 没有的字段，还有同名字段但是类型不一样的字段（此类情况最好直接能调用 idea 的告警将类型不一样的字段告警出来）；
2.在点击 target 的 setxxx 方法时能把使用 copyProperties 方法的地方作为其引用。
楼主要是能把这两个功能实现一下这个插件的价值会更大些。

没啥区别，不想用 Mybatis Plus 想用原生 Mybatis 就可以使用 PageHelper ，不然就直接用 Mybatis Plus 自带的分页好了，不过 Mybatis Plus 确实比较糙，我也贡献过对 limit 的一个优先

杭州 java 2.5w 6 年

用来凑数的，我自己在公司也提交过，主要是给公司免税还有申请什么资质之类的使用，过了还有钱拿。

我去年从网易云切换到 notion 了，体验真的爽飞。

可观测性比较适用于大型成熟系统，小项目基础设施搞得再好如果只有零星几个开发那也没多少收益。可观测性目前主要分为几大块，log （日志）、trace(链路）、metrics （监控）、alarm （告警），对于小项目来说要有取舍，比如题中提到的 skywalking 我司目前也是用的这个并做了二开但是这是建立在核心系统有超过 60 个应用，上千个 pod 的基础之上的，小项目哪怕使用微服务应用数也很有限，链路本身就不复杂，所以链路的优先级远远低于日志（日志中有 tid 其实可以脑补串联起链路），剩下的监控和告警常常是一起的，Prometheus 几乎是事实意义上的标准了，只有告警成本较高收益不明显，资源告警和业务告警搞起来不要太复杂。所以小项目资源紧张的情况下优先保障日志（日志规范其实也很有讲究有很多技术手段可以做），其次有空余资源就把监控（ jvm 内存、进程内存、gc 、cpu 、磁盘 io 、网络 io ）搞起来，链路和告警可以在项目有更大的发展之后再逐步引入。

结论是没有。
好处之一有点类似我们自己工程中的多 module 结构一样，看源码的时候可以更清晰，引入依赖可以按需引入而不是全量引入，很多框架以前为了这个事情自己把使用的类从 jdk 里面 copy 出来（ copy 一个类往往还没用还要 copy 依赖的类想想心累不），有了模块化以后就不用再干这种脏活了，当然上面的事情和 web 业务开发基本没啥关系，主要是框架和中间件影响比较大，但其实这一举措主要是 java 还不想放弃桌面端，java 做桌面端以前最被人诟病的就是要带着 jre 一起发布整个包大到离谱，有了模块化用户就可以自己裁剪出需要的 jre 能显著地降低包的体积有利于分发；
第二点就是精细化权限，我可太喜欢这个东西了，甚至一度想把我司的屎山从 jdk8 迁移到 17 ，虽然最后没有成型，比较典型的一个场景是框架中 A module 的类只想给自己框架内部的其它 module 使用，但是很难做到这一点，设为 default 则要求其它模块使用它的类的包名与其一致，设为 public 则存在被业务滥用的风险，现在总归存在一种机制能解决这个事情了。