V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  firefffffffffly  ›  全部回复第 1 页 / 共 3 页
回复总数  47
1  2  3  
2020-01-21 16:09:24 +08:00
回复了 hunterJax 创建的主题 健康 想问问大家心脏有过异常感吗?
心脏感觉有问题,绝对一定要听医生的说法,不要自我怀疑,因为心脏是全身对自我怀疑最敏感的部位,你认为它不舒服,它就会一直不舒服,遵从医生的检查建议和检查结果打消怀疑最重要。我有过类似的经历,充分医学检查后一定要相信检查结果,不然心脏会一直表现得有问题。
2019-08-23 14:13:15 +08:00
回复了 xujinkai 创建的主题 程序员 大家工作中都遇到过哪些神奇的代码
for(int i=0;i<3;i++) {
switch(i) {
case 0:
doSth();
break;
case 1:
doSth2();
break;
case 2:
doSth3();
break;
}
}
花钱找声乐老师学是一个很有用的办法,现在提供这个服务的机构个人挺多的。免费教学资源的话推荐去 youtube 或 bilibili 搜嘎老师的视频,讲解比较通俗易懂而且真的很有用。
2019-07-09 11:04:07 +08:00
回复了 EthanDon 创建的主题 程序员 确认一下, http 的长连接是不是客户端没法发送二次数据?
http2 多路复用解决了这个问题
2019-06-26 17:40:08 +08:00
回复了 hackingwu 创建的主题 程序员 反射性能差这么多,有办法提高吗?
性能有差距,但是应该不会像例子里这么大, 这段代码做 benchmark 不太严谨,比如第二段代码可能会被 jit 优化到没有。
依照这个测试 https://dzone.com/articles/the-performance-cost-of-reflection 不包含具体逻辑的情况下测试大约是差 10 倍。
2019-06-18 14:21:42 +08:00
回复了 gramyang 创建的主题 Java 终于研究明白了, concurrenthashmap 的 get 然后 put 的并发问题
@gramyang

每个接触 concurrenthashmap 的人都踩过的坑 ×
不理解线程安全的人踩过的坑 √

increase1 的线程不安全发生在 int value = oldTable.getI(); oldTable.setI(value + 1);这两句上
increase2 使用 CAS 乐观锁的方式解决了 increase1 里线程不安全的问题,你也可以用传统的 synchornized 悲观锁同样解决问题。
无论怎样都没有涉及到 CHM 的任何问题。
2019-06-17 11:50:22 +08:00
回复了 KunMinX 创建的主题 Android 重学安卓:绝不丢失状态的 Activity 重建机制!
1. Saved instance state 也是基于序列化与反序列化的磁盘访问,与设计良好的自定义持久化缓存性能应该没有区别,自定义持久化性能问题主要来自于持久化方式的设计问题。

2. 自定义持久化的生命周期是比 Saved instance state 要长的,可以做到 activity 反复 finish/start 之后也能共享数据,这个场景是不能被 SavedInstanceState 取代的,不过这个应该不是这篇文章的重点。

3. 由于 SavedInstanceState 的性能问题,android 官方推荐将页面状态拆分,使用 ViewModel 模式内存存储绝大部分状态,小部分关键状态交给 SavedInstanceState 保存。

4. 大部分状态保持问题并非是使用错了方式,而是没有理清页面上所存在的状态,导致状态只有一部分被恢复 /保存,进而把整个页面逻辑导向到不可预测的方向。

5. 推荐其他开发者使用 android:configChanges 时,最好同时告诉他们可能存在的副作用: https://developer.android.com/guide/topics/resources/runtime-changes.html#HandlingTheChange

以上内容均总结于官方文档( https://developer.android.com/topic/libraries/architecture/saving-states
2019-06-13 12:38:38 +08:00
回复了 petelin 创建的主题 问与答 在服务端写业务的时候, 面向对象和面向过程到底哪个更好?
粗略思考了一下,我觉得问题关键在于 stateless 和 stateful 之间的区别,面向对象能写出 stateless 的代码,面向过程也可能被写成 stateful,纯函数式编程能真正做到 stateless,但函数式编程又会带来额外的难度。
2019-06-12 10:41:50 +08:00
回复了 gramyang 创建的主题 Java ConcurrentHashMap 的使用问题
建议把 exception 信息贴出来,这样能轻松确定是 map 为空还是传入的 key 值为空。
从描述的 exception 来看 player 最不可能为空,因为这样的话报错 message 和 traces 里是不会包含 remove 相关内容的,因为在 player.getNum()时就会报错了,remove 函数还没有入栈。
key 值为空的情况,就是 player.getNum()的结果为 null,这个 player 内部属性需要再检查一下是否有多线程修改。
2019-06-06 12:17:10 +08:00
回复了 Krma 创建的主题 程序员 框架可以解决的问题需要逻辑上再做单独处理吗?
我的理解框架可以做这种通用逻辑,但是很重要的一点是框架绝不能隐藏或者掩盖这些逻辑产生的信息,越重要的信息就越应该越明显的暴露给业务层,这样才能保证调用方对框架接口产生足够清晰的预期。

比如你的引导框架有 show()/hide()两个接口,这时候如果你将 show()中加入只能展示一次的逻辑,这时 show()接口是否真正生效,就应该是非常重要的信息(在编写框架时,不能提前假设调用方用不到这个信息),暴露这个信息就很多种方式,比如如下几个,越往下的提示越明显。

boolean show() 用返回值是否成功 show

initShowType(int type, int maxTimes)和 show(type), 提供提前初始化引导的接口显式提示这个逻辑

show(int maxTimes) 用显式参数让调用方察觉这个逻辑存在

show() throw AlreadyShownException 最明显的提示,迫使调用方必须考虑这个情况

具体的理想实现方法还要同时参考很多其他的设计原则,而且也依赖具体场景。比如你暴露了过多的信息,就会违反最小知识原则,让业务层需要关注太多不必要信息。
2019-06-06 10:22:31 +08:00
回复了 deeplee 创建的主题 Java 刚刚面试阿里,面试管说 synchronized 是非可重入的。。。
@deeplee 应该是被钓鱼了,他佯装惊讶问你。早些年也上过钩,当时一下就懵了。
2019-06-05 14:35:18 +08:00
回复了 h8743 创建的主题 Java Java 实现 输入 AA 输出 AB ..输入 AZ 输出 BA 一直到输出 ZZ
if(input == "AA") {
System.out.println("AB");
} else if(input == "AZ") {
System.out.println("BA 一到输出 ZZ");
}

自己的作业自己做
2019-06-05 14:03:51 +08:00
回复了 Freeego 创建的主题 程序员 有什么办法可以取到距离最近的整数?
Math.ceil
Math.floor
Math.round
有 id 存在的场景不用 id 索引内容而是用展示性质的 name 做索引肯定是最大的坑,所以肯定不能返回 name 让他做查询操作。
我理解你返回了 { "data": [{"id":1,"name":"whw1"},{"id":3,"name":"whw3"},{"id":5,"name":"whw5"}], "selectedId": 3}
首先这就是个数据结构设计问题,和 Android 平台不相关。
我猜他 UI 层额外创建了个只包含 name 的 List,想用 indexOf 或者 contains 函数直接查询 index,如果只有 id 就得先从 id 查询 name,再查询 index,就多了个 id 查 name 的循环。
2019-05-29 15:06:27 +08:00
回复了 aoscici2000 创建的主题 Java 还是 Futrue.get() 堵塞当前线程的问题
1. 你这里涉及到两个多线程,一个是 check()请求函数发生的线程池 executorA,一个是你自己定义执行 CheckPrice 的 executorB
2. 你的问题和 executorB 没有太大关系,它的线程数只影响 Future.get()的耗时,最少 2s, 任何类型的 Future.get()一样会阻塞至少 2s。
3. 由 2 可知你每次 check()函数被调用最少会阻塞 2s,这时 executorA 如果是单线程模型,两个请求一定会有一个等待 4s。
4. executorA 线程数取决于 servlet 容器的配置

解决方案
1. 修改 servlet 的配置,增加 executorA 线程数,治标不治本,优点是简单
2. check()修改为异步非阻塞返回模型,参考你之前帖子里 9 楼回复的 CompletableFuture + DeferredResult 方案
2019-03-12 15:26:22 +08:00
回复了 rizon 创建的主题 程序员 Java 范型 接口怎么写数组?
直接传 SFunction<T, ?>[] 类型的数组没有问题吧
2018-11-19 12:05:03 +08:00
回复了 singlepig 创建的主题 Android Android KTX 这是凉了么?
2018-11-19 11:50:43 +08:00
回复了 singlepig 创建的主题 Android Android KTX 这是凉了么?
拢共就三句话,看完啊老弟
1  2  3  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1777 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 41ms · UTC 16:43 · PVG 00:43 · LAX 08:43 · JFK 11:43
Developed with CodeLauncher
♥ Do have faith in what you're doing.