Какъв е основният проблем на тази реализация - Свързването към Redis е хардкоднато - Има пул от връзки към Redis - Не провереното извикване `jedis.get` може да върне null - Използването на командата `KEYS`, която натоварва сървъра - Няма събития Redis
Каква е основната причина за неправилното поведение на кода? Нарушена е неизменяемостта на обектите Не се управлява състоянието на прекъсване Производителността се влошава поради блокиране Конфликтът на блокиращи обекти води до мъртва точка Прекомерна синхронизация на ресурси Несъздадени състояния на обектитеimport java.util.concurrent.*; class Competition { private final Object lock = new Object(); public void syncMethodA(Competition competitor) { synchronized (lock) { try { Thread.sleep(100); } catch (InterruptedException e) {} competitor.syncMethodB(this); } } public void syncMethodB(Competition competitor) { synchronized (lock) { try { Thread.sleep(100); } catch (InterruptedException e) {} competitor.syncMethodA(this); } } } public class FitnessApp { public static void main(String[] args) { Competition comp1 = new Competition(); Competition comp2 = new Competition(); Thread t1 = new Thread(() -> comp1.syncMethodA(comp2)); Thread t2 = new Thread(() -> comp2.syncMethodB(comp1)); t1.start(); t2.start(); } }
Какъв е основният проблем на избраната структура на решението - Твърда връзка, ниска гъвкавост - Нарушаване на полиморфизма при обработка на елементи - Няма фабричен метод за WardrobeItem - Няма патърн Адаптер за новите оптимизатори - Високотарифни операции в рамките на оптимизацията
Какъв е основният проблем на този пример Dockerfile FROM golang:1.16 WORKDIR /app COPY go.mod . COPY go.sum . RUN go mod download COPY . . RUN go build -o crashAnalysis . CMD ["./crashAnalysis"] EXPOSE 9090 - Липсва ENV за конфигурация - Няма многостепенни билдове - Временните файлове никога не се изтриват - Неоптимално използване на RUN - Порт 8081 не е указан в инструкцията EXPOSE
Какво се връща на продюсъра, ако изпрати ID, който вече е бил изпратен преди известно време (период на идемпотентност 6 часа)?
Каква е основната причина за неправилното поведение на кода при използване на неизменяема карта? Полета без "само за четене" могат да бъдат променяни HashMap не запазва реда на елементите Прекомерната употреба на обвивки причинява объркване Картата "Неизменяема" отразява промените в оригиналната карта Неправилната употреба на обекта води до грешка
Защо там няма изявления? Защо не изпълнява компилация на изявлението на базата?
Говори за идемпотентно изпращане или Exactly-Once в Kafka. Кое използва?
Как си общо взето с DevOps технологиите — Kubernetes, CI/CD и други?
Как трябва приложението да определя в коя проба има Kafka връзки, има ли теми? Как да реализираме Health Check за Kafka?
Какъв е основният проблем на тази реализация? - Не се използва кеш в паметта за оптимизация. - Различни типове съхранение на данни в един хеш - Проверка на превключвателя преди четене на данни не дава резултати - Липсват стандартни сериализатори в `RedisTemplate` - Пайплайнът не се използва за частични операции
Какъв е надвишението на Kafka при идемпотентно изпращане? Какво жертва Kafka в такъв случай?
Как да проверите дали темата е активна и има необходимия брой партиции, и дали има поне един лидер в партицията?
ДЛТ потребителят беше в същата услуга като основната? Защо да го слушаме отново и да го логваме?
Какво да направим, ако искаме да направим същото с DataSource?
Когато правиш обикновен SELECT, колко заявки изпраща драйверът към Postgres? Какви заявки и какво ще има в тях?
Трябва да прихващаме всички заявки в Kafka и да ги изпращаме към системата за одит или телеметрия. Как би го направил?
На кой протокол на транспортно ниво работи HTTP?
Ако имаме външен API, който разрешава максимум 10 едновременни връзки, кой клас от пакета java.util.concurrent бихте използвали, за да ограничите броя на паралелните извиквания?
Разкажи за релевантния опит от последната ти работа — какво ти хареса, какво не?
